Ihr braucht lediglich drei Vorlagen:
Die neue Variablenstruktur und Berechnungslogik bleiben dabei erhalten.
Ich habe dafür Codex verwendet.
Der kann die VLG-Dateien selbstständig entpacken, bearbeiten und wieder zusammensetzen.
Einfach die drei Vorlagen zusammen mit dem Prompt an einen KI-Agenten übergeben und loslegen.
Die fertige Vorlage natürlich einmal in der Wawi testen, bevor ihr sie produktiv verwendet.
- Die originale JTL-Standardvorlage 1.0
- Eure individuell angepasste Vorlage 1.0
- Die originale JTL-Standardvorlage 2.0
Die neue Variablenstruktur und Berechnungslogik bleiben dabei erhalten.
Ich habe dafür Codex verwendet.
Der kann die VLG-Dateien selbstständig entpacken, bearbeiten und wieder zusammensetzen.
Einfach die drei Vorlagen zusammen mit dem Prompt an einen KI-Agenten übergeben und loslegen.
Die fertige Vorlage natürlich einmal in der Wawi testen, bevor ihr sie produktiv verwendet.
# 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
Alle drei Vorlagen müssen denselben Belegtyp betreffen (z. B. Rechnung).
Die Standardvorlage 1.0 soll möglichst genau der ursprünglichen Ausgangsvorlage der angepassten 1.0-Vorlage entsprechen (Design, Sprache und Ausgangsstand). Falls sie nicht passt oder fehlt, weise darauf hin: Dann lassen sich individuelle Anpassungen nicht mit derselben Sicherheit isolieren.
Die Bezeichnungen Ausgabe 1.0 und Ausgabe 2.0 meinen die Generation der JTL-Ausgabevorlagen, nicht die installierte JTL-Wawi-Version.
## 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.
JTL-`.vlg`-Exporte sind ZIP-Archive. Prüfe den tatsächlichen Dateityp, bevor du sie entpackst, und brich mit einer verständlichen Fehlermeldung ab, wenn eine Datei beschädigt oder kein lesbares Archiv ist.
Entpacke jede Vorlage in ein eigenes Arbeitsverzeichnis. Erhalte die vollständige Verzeichnis- und Dateistruktur, die relevanten Dateinamen, Referenzen, Zeichencodierungen und Ressourcen. Beachte insbesondere die Zuordnung von Projektdateien (z. B. `.lst`), XML-Dateien, Bildern und Konfigurationen; gehe nicht davon aus, dass jedes Archiv genau eine `.lst` enthält.
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 eine eigenständige, korrekt aufgebaute `.vlg`-Datei entstehen. Packe den ursprünglichen Archivinhalt ohne zusätzliche Verzeichnisebene; benenne die Datei nicht einfach um, ohne das Archivformat zu prüfen. Kontrolliere die Paketstruktur und alle Referenzen.
Falls du die Dateiformate oder die Projektstruktur nicht zuverlässig lesen und bearbeiten kannst, melde dies ausdrücklich. Gib in diesem Fall keine vermeintlich fertige oder geprüfte `.vlg` aus.
---
## 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. Berücksichtige dabei, ob die Standardvorlage wirklich die passende Ausgangsbasis ist. Technische Abweichungen durch unterschiedliche Erstellungsstände oder Vorlagendesigns dürfen nicht pauschal als Anpassungen des Anwenders gelten.
Dazu gehören beispielsweise:
- Texte
- Bezeichnungen
- Logos
- Bilder
- Positionen
- Größen
- Schriftarten
- Schriftgrößen
- Tabellen
- Spalten
- Kopfbereiche
- Fußbereiche
- zusätzliche Objekte
- entfernte oder ausgeblendete Objekte
- Bedingungen
- Formeln
- Gruppierungen
- Seitenumbrüche
- Summen
- Druckbedingungen
- List-&-Label-Ausdrücke
- eigene SQL-Abfragen
- benutzerdefinierte Berechnungen
Unterscheide dabei klar zwischen:
1. individuellen Änderungen des Benutzers
2. technischen Änderungen, die JTL zwischen Ausgabe 1.0 und Ausgabe 2.0 vorgenommen hat
3. Unterschieden durch abweichende Ausgangsstände oder Vorlagendesigns, soweit feststellbar
---
## 3. Standard 2.0 ist die technische Grundlage
Die Standardvorlage Ausgabe 2.0 ist die maßgebliche technische Referenz.
Sie hat Vorrang bei:
- Datenquellen
- Variablen
- Tabellen
- Relationen
- Summenlogik
- Steuerlogik
- Rundungen
- Betragsberechnungen
- List-&-Label-Ausdrücken
- aktueller JTL-Ausgabestruktur
Übernimm keine alten technischen Strukturen aus Ausgabe 1.0, wenn Ausgabe 2.0 bereits eine aktuelle Lösung besitzt.
Insbesondere dürfen alte Variablen aus Ausgabe 1.0 nicht einfach in die neue Vorlage kopiert werden.
---
## 4. Keine Variablen erfinden
Erfinde niemals:
- Variablennamen
- Datenquellen
- Tabellen
- Felder
- Funktionen
- Relationen
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 und du Zugriff darauf hast, darfst du zusätzlich offizielle Dokumentation verwenden, insbesondere:
- offizielle JTL-Dokumentation
- offizielle List-&-Label-Dokumentation
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. Erkläre insbesondere, wenn eine in 1.0 genutzte Funktion in der bereitgestellten Standardvorlage 2.0 nicht erkennbar verfügbar ist. Eine äußerlich ähnliche Variable ist noch kein Beleg dafür, dass Dateninhalt, Typ und Berechnungslogik identisch sind.
---
## 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
- Fremdwährungen, Mehrsprachigkeit und unterschiedliche Steuerfälle
- E-Rechnungsbestandteile (sofern enthalten)
Ü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
11. einer Einschätzung, ob die drei Vorlagen als Vergleichsgrundlage geeignet sind
Führe erst danach die eigentliche Migration durch. Trenne im Bericht klar zwischen sicher erkannten Anpassungen, begründeten Vermutungen und offenen Fragen. Falls die Vergleichsgrundlage unbrauchbar ist oder wesentliche Zuordnungen fehlen, halte an und fordere die erforderliche Klärung an, statt zu raten.
---
## 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
Ändere, soweit nötig, nur die konkret betroffenen Projekte und Referenzen des Archivs. Behalte die Verbindung zwischen Bestandteilen der Vorlage bei. Wenn für eine Funktion neue SQL-Abfragen oder zusätzliche Datenquellen erforderlich werden, dokumentiere Herkunft, Zweck und Kompatibilität; führe weder Datenbankänderungen noch schreibende Datenbankoperationen durch.
---
## 8. Abschließende Prüfung: Datei und JTL-Funktion getrennt betrachten
### A. Technische Dateiprüfung (durch den KI-Agenten)
Prüfe nach der Migration, soweit mit den verfügbaren Werkzeugen zuverlässig möglich:
- 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?
- Ist das Ergebnisarchiv lesbar und sind alle referenzierten Dateien vorhanden?
- Wurden nicht migrierte oder bewusst verworfene Anpassungen erfasst?
Wichtig: Ohne JTL-Laufzeit, Datenquellen und echte Beispieldaten sind viele fachliche Prüfungen nur statische Plausibilitätsprüfungen. Behaupte nicht, eine tatsächlich korrekte Ausgabe, Berechnung oder Steuerbehandlung nachgewiesen zu haben, wenn das nicht geschehen ist.
### B. Funktionstest in JTL-Wawi (durch den Anwender)
Liefere eine konkrete Test-Checkliste. Mindestens prüfen:
- Lässt sich die neue `.vlg` als **separate Testvorlage** importieren und im Designer öffnen?
- Entsprechen Layout, Logo, Texte, Positionen und Umbrüche der bisherigen Vorlage?
- Sind Belege mit einer und mehreren Positionen sowie mehrseitige Belege korrekt?
- Stimmen Netto, Brutto, Steuern, Versand, Rabatte, Rundungen und Gesamtsummen anhand bekannter Testbelege?
- Funktionieren Sonderfälle, die für den Betrieb tatsächlich vorkommen (z. B. Steuerbefreiung, Ausland, Fremdwährung, abweichende Sprache, kundenspezifische Bedingungen)?
- Funktionieren die genutzten Ausgabewege (z. B. Speichern, Drucken, E-Mail)?
- Bei Rechnungen mit ZUGFeRD/XRechnung: Entstehen die erwarteten XML-Daten und bestehen sie die erforderliche fachliche und technische Validierung?
Importieren, Drucken und fachliche Validierung dürfen im Abschlussbericht nur dann als **bestanden** gelten, wenn sie wirklich ausgeführt wurden. Andernfalls ausdrücklich **nicht geprüft – Anwender-Test erforderlich** melden.
---
## 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
- Kennzeichnung **automatisch geprüft** / **plausibel, nicht zur Laufzeit geprüft** / **offen**
Liefere als Ergebnis die neue `.vlg` (nur sofern technisch erfolgreich erstellt), den Analysebericht, das Änderungsprotokoll sowie die Test-Checkliste. Gib die Originale unverändert zurück bzw. lasse sie unangetastet.
---
## 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
7. keine falsche Aussage über erfolgreich durchgeführte Tests
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
Alle drei Vorlagen müssen denselben Belegtyp betreffen (z. B. Rechnung).
Die Standardvorlage 1.0 soll möglichst genau der ursprünglichen Ausgangsvorlage der angepassten 1.0-Vorlage entsprechen (Design, Sprache und Ausgangsstand). Falls sie nicht passt oder fehlt, weise darauf hin: Dann lassen sich individuelle Anpassungen nicht mit derselben Sicherheit isolieren.
Die Bezeichnungen Ausgabe 1.0 und Ausgabe 2.0 meinen die Generation der JTL-Ausgabevorlagen, nicht die installierte JTL-Wawi-Version.
## 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.
JTL-`.vlg`-Exporte sind ZIP-Archive. Prüfe den tatsächlichen Dateityp, bevor du sie entpackst, und brich mit einer verständlichen Fehlermeldung ab, wenn eine Datei beschädigt oder kein lesbares Archiv ist.
Entpacke jede Vorlage in ein eigenes Arbeitsverzeichnis. Erhalte die vollständige Verzeichnis- und Dateistruktur, die relevanten Dateinamen, Referenzen, Zeichencodierungen und Ressourcen. Beachte insbesondere die Zuordnung von Projektdateien (z. B. `.lst`), XML-Dateien, Bildern und Konfigurationen; gehe nicht davon aus, dass jedes Archiv genau eine `.lst` enthält.
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 eine eigenständige, korrekt aufgebaute `.vlg`-Datei entstehen. Packe den ursprünglichen Archivinhalt ohne zusätzliche Verzeichnisebene; benenne die Datei nicht einfach um, ohne das Archivformat zu prüfen. Kontrolliere die Paketstruktur und alle Referenzen.
Falls du die Dateiformate oder die Projektstruktur nicht zuverlässig lesen und bearbeiten kannst, melde dies ausdrücklich. Gib in diesem Fall keine vermeintlich fertige oder geprüfte `.vlg` aus.
---
## 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. Berücksichtige dabei, ob die Standardvorlage wirklich die passende Ausgangsbasis ist. Technische Abweichungen durch unterschiedliche Erstellungsstände oder Vorlagendesigns dürfen nicht pauschal als Anpassungen des Anwenders gelten.
Dazu gehören beispielsweise:
- Texte
- Bezeichnungen
- Logos
- Bilder
- Positionen
- Größen
- Schriftarten
- Schriftgrößen
- Tabellen
- Spalten
- Kopfbereiche
- Fußbereiche
- zusätzliche Objekte
- entfernte oder ausgeblendete Objekte
- Bedingungen
- Formeln
- Gruppierungen
- Seitenumbrüche
- Summen
- Druckbedingungen
- List-&-Label-Ausdrücke
- eigene SQL-Abfragen
- benutzerdefinierte Berechnungen
Unterscheide dabei klar zwischen:
1. individuellen Änderungen des Benutzers
2. technischen Änderungen, die JTL zwischen Ausgabe 1.0 und Ausgabe 2.0 vorgenommen hat
3. Unterschieden durch abweichende Ausgangsstände oder Vorlagendesigns, soweit feststellbar
---
## 3. Standard 2.0 ist die technische Grundlage
Die Standardvorlage Ausgabe 2.0 ist die maßgebliche technische Referenz.
Sie hat Vorrang bei:
- Datenquellen
- Variablen
- Tabellen
- Relationen
- Summenlogik
- Steuerlogik
- Rundungen
- Betragsberechnungen
- List-&-Label-Ausdrücken
- aktueller JTL-Ausgabestruktur
Übernimm keine alten technischen Strukturen aus Ausgabe 1.0, wenn Ausgabe 2.0 bereits eine aktuelle Lösung besitzt.
Insbesondere dürfen alte Variablen aus Ausgabe 1.0 nicht einfach in die neue Vorlage kopiert werden.
---
## 4. Keine Variablen erfinden
Erfinde niemals:
- Variablennamen
- Datenquellen
- Tabellen
- Felder
- Funktionen
- Relationen
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 und du Zugriff darauf hast, darfst du zusätzlich offizielle Dokumentation verwenden, insbesondere:
- offizielle JTL-Dokumentation
- offizielle List-&-Label-Dokumentation
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. Erkläre insbesondere, wenn eine in 1.0 genutzte Funktion in der bereitgestellten Standardvorlage 2.0 nicht erkennbar verfügbar ist. Eine äußerlich ähnliche Variable ist noch kein Beleg dafür, dass Dateninhalt, Typ und Berechnungslogik identisch sind.
---
## 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
- Fremdwährungen, Mehrsprachigkeit und unterschiedliche Steuerfälle
- E-Rechnungsbestandteile (sofern enthalten)
Ü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
11. einer Einschätzung, ob die drei Vorlagen als Vergleichsgrundlage geeignet sind
Führe erst danach die eigentliche Migration durch. Trenne im Bericht klar zwischen sicher erkannten Anpassungen, begründeten Vermutungen und offenen Fragen. Falls die Vergleichsgrundlage unbrauchbar ist oder wesentliche Zuordnungen fehlen, halte an und fordere die erforderliche Klärung an, statt zu raten.
---
## 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
Ändere, soweit nötig, nur die konkret betroffenen Projekte und Referenzen des Archivs. Behalte die Verbindung zwischen Bestandteilen der Vorlage bei. Wenn für eine Funktion neue SQL-Abfragen oder zusätzliche Datenquellen erforderlich werden, dokumentiere Herkunft, Zweck und Kompatibilität; führe weder Datenbankänderungen noch schreibende Datenbankoperationen durch.
---
## 8. Abschließende Prüfung: Datei und JTL-Funktion getrennt betrachten
### A. Technische Dateiprüfung (durch den KI-Agenten)
Prüfe nach der Migration, soweit mit den verfügbaren Werkzeugen zuverlässig möglich:
- 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?
- Ist das Ergebnisarchiv lesbar und sind alle referenzierten Dateien vorhanden?
- Wurden nicht migrierte oder bewusst verworfene Anpassungen erfasst?
Wichtig: Ohne JTL-Laufzeit, Datenquellen und echte Beispieldaten sind viele fachliche Prüfungen nur statische Plausibilitätsprüfungen. Behaupte nicht, eine tatsächlich korrekte Ausgabe, Berechnung oder Steuerbehandlung nachgewiesen zu haben, wenn das nicht geschehen ist.
### B. Funktionstest in JTL-Wawi (durch den Anwender)
Liefere eine konkrete Test-Checkliste. Mindestens prüfen:
- Lässt sich die neue `.vlg` als **separate Testvorlage** importieren und im Designer öffnen?
- Entsprechen Layout, Logo, Texte, Positionen und Umbrüche der bisherigen Vorlage?
- Sind Belege mit einer und mehreren Positionen sowie mehrseitige Belege korrekt?
- Stimmen Netto, Brutto, Steuern, Versand, Rabatte, Rundungen und Gesamtsummen anhand bekannter Testbelege?
- Funktionieren Sonderfälle, die für den Betrieb tatsächlich vorkommen (z. B. Steuerbefreiung, Ausland, Fremdwährung, abweichende Sprache, kundenspezifische Bedingungen)?
- Funktionieren die genutzten Ausgabewege (z. B. Speichern, Drucken, E-Mail)?
- Bei Rechnungen mit ZUGFeRD/XRechnung: Entstehen die erwarteten XML-Daten und bestehen sie die erforderliche fachliche und technische Validierung?
Importieren, Drucken und fachliche Validierung dürfen im Abschlussbericht nur dann als **bestanden** gelten, wenn sie wirklich ausgeführt wurden. Andernfalls ausdrücklich **nicht geprüft – Anwender-Test erforderlich** melden.
---
## 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
- Kennzeichnung **automatisch geprüft** / **plausibel, nicht zur Laufzeit geprüft** / **offen**
Liefere als Ergebnis die neue `.vlg` (nur sofern technisch erfolgreich erstellt), den Analysebericht, das Änderungsprotokoll sowie die Test-Checkliste. Gib die Originale unverändert zurück bzw. lasse sie unangetastet.
---
## 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
7. keine falsche Aussage über erfolgreich durchgeführte Tests
