Dann könnt ihr auch den Wert gar nicht speichern, weil in der Speicherroutine wird abgefragt, ob der Wert verändert wurde. Und wenn das Veränderungsereignis nicht abgefeuert wird, wird das Attributwert nicht übernommen.
Globale Textbausteine – Inhalte werden nicht gespeichert (Wawi 1.11.1)
- Ersteller des Themas Dele
- Erstellungsdatum
-
- Schlagworte
- globale textbausteine
Danke @mvh, dann sind wir dem Fehler ja schon sehr weit auf der Spur. Ich hoffe auf eine Blitzlösung von JTL.
Wird die Speicherroutine aufgerufen und ruft diese eine StoredProcedure in der Bank auf? Wenn ja, könnte man als Workarround die Abfrage nach der Änderung in der StoredProcedure auskommentieren und einfach immer speichern. Denke ich da richtig?
Moin. Die Speicherroutine ist im Code und die Ereignisse auch, es kann nur JTL korrigieren.
Ich erkläre es etwas genauer:
Das Ereignis heißt: WertOnPropertyChanged und er erwartet eine Property/Eigenschaft: BenutzerInhaltWertAsString
und wenn das Event/Ereignis "richtig" ankommt wird es zu einer internen Liste WertChangedList hinzugefügt.
und in der SaveChanges()-Funktion wird letztendlich diese Liste benutzt, um festzustellen, was verändert wurde
Nur leider feuert das Textfeld dieses Ereignis nicht und dann wird nichts gespeichert.
Das Ereignis heißt: WertOnPropertyChanged und er erwartet eine Property/Eigenschaft: BenutzerInhaltWertAsString
und wenn das Event/Ereignis "richtig" ankommt wird es zu einer internen Liste WertChangedList hinzugefügt.
und in der SaveChanges()-Funktion wird letztendlich diese Liste benutzt, um festzustellen, was verändert wurde
C#:
foreach (GlobalerTextValue globalerTextValue in this.EditorViewModel.WertChangedList)Und das ist ne Kleinigkeit, ich weiß gar nicht, warum das nicht am gleichen Tag behoben wird.
Als wenn einer an der UI rumtüfftel und dann nicht mal das testet was er da gemacht hat.
Als wenn einer an der UI rumtüfftel und dann nicht mal das testet was er da gemacht hat.
Es ist eine Kleinigkeit, wenn jemand sich die Mühe macht, den ganzen Ablauf komplett verfolgt und die Lösung dafür präsentiert.
Moin.
Das "alte" Ticket wurde abgewiesen und dafür das "richtige" 1.11 Ticket https://issues.jtl-software.de/issues/WAWI-85988 wird schon bearbeitet.
Warten wir ab, wie schnell es gelöst wird.
Das "alte" Ticket wurde abgewiesen und dafür das "richtige" 1.11 Ticket https://issues.jtl-software.de/issues/WAWI-85988 wird schon bearbeitet.
Warten wir ab, wie schnell es gelöst wird.
Ich bin fassungslos.
Der Fehler bei der Speicherung globaler Textbausteine wurde bereits am 19.10. für JTL-Wawi 1.11.1 gemeldet. Inzwischen sind 1.11.2, 1.11.3, 1.11.4 und nun 1.11.5 erschienen – ohne dass dieser Fehler behoben wurde.
Ich arbeite aktuell produktiv mit JTL-Wawi 1.11.5 und kann bestätigen: Globale Textbausteine lassen sich weiterhin nicht speichern, Änderungen werden ohne Fehlermeldung nicht übernommen, es kommte keine Fehlermeldung oder Hinweis.
Für mich ist das besonders kritisch, da sämtliche meiner eBay-Artikel auf globalen Textbausteinen basieren. Ich kann aktuell keine Änderungen vornehmen, was faktisch bedeutet, dass ich gezwungen wäre, hunderte Artikel manuell neu zu schreiben – und das über die Feiertage an Neujahr.
Das ist kein akzeptabler Zustand. Wir sprechen hier über eine zentrale Kernfunktion, deren Ausfall massive Auswirkungen auf produktive Systeme hat. Dass dieser Fehler:
Ich erwarte eine klare Stellungnahme, eine offizielle Information an betroffene Nutzer sowie eine zeitnahe Fehlerbehebung oder zumindest einen belastbaren Workaround.
Sollte sich hier kurzfristig nichts bewegen, muss ich das Thema nach den Feiertagen rechtlich prüfen lassen, da hier meine Einahmequelle direkt ins Herz getroffen wurde.
Edit:
Ich habe soeben geprüft, wann ich das Update installiert habe, das mir diese Situation eingebrockt hat: mit Erscheinen von JTL-Wawi 1.11.5, also vor rund zwei Wochen. Das vorletzte Update erfolgte im Sommer 2025 und lief bei mir problemlos.
Fazit für mich: Zum Zeitpunkt meiner Installation war JTL dieser Fehler bereits bekannt, dennoch erfolgte keine Information oder Warnung. Wirtschaftlich und kommunikativ ist das nicht vertretbar. Niemand erwartet eine sofortige Fehlerbehebung, wohl aber Transparenz und klare Kommunikation.
In meinem konkreten Fall hätte ein einfacher Hinweis, Updates ab 1.11.1 vorerst nicht zu installieren, einen erheblichen finanziellen Schaden verhindert. Stattdessen wurde das Risiko vollständig auf die Anwender verlagert.
Zusätzlich entsteht der Eindruck, dass entweder die Tragweite dieses Fehlers – insbesondere für Nutzer, die mit globalen Feldern und Textbausteinen arbeiten – unterschätzt wird, oder dass entsprechende Tickets mit niedriger Priorität über längere Zeit unbearbeitet bleiben. Beides wäre problematisch.
Der Fehler bei der Speicherung globaler Textbausteine wurde bereits am 19.10. für JTL-Wawi 1.11.1 gemeldet. Inzwischen sind 1.11.2, 1.11.3, 1.11.4 und nun 1.11.5 erschienen – ohne dass dieser Fehler behoben wurde.
Ich arbeite aktuell produktiv mit JTL-Wawi 1.11.5 und kann bestätigen: Globale Textbausteine lassen sich weiterhin nicht speichern, Änderungen werden ohne Fehlermeldung nicht übernommen, es kommte keine Fehlermeldung oder Hinweis.
Für mich ist das besonders kritisch, da sämtliche meiner eBay-Artikel auf globalen Textbausteinen basieren. Ich kann aktuell keine Änderungen vornehmen, was faktisch bedeutet, dass ich gezwungen wäre, hunderte Artikel manuell neu zu schreiben – und das über die Feiertage an Neujahr.
Das ist kein akzeptabler Zustand. Wir sprechen hier über eine zentrale Kernfunktion, deren Ausfall massive Auswirkungen auf produktive Systeme hat. Dass dieser Fehler:
- seit über zwei Monaten bekannt ist,
- durch fünf Patch-Versionen hindurch nicht behoben wurde,
- und keine aktive Information an zahlende Kunden erfolgt ist,
Ich erwarte eine klare Stellungnahme, eine offizielle Information an betroffene Nutzer sowie eine zeitnahe Fehlerbehebung oder zumindest einen belastbaren Workaround.
Sollte sich hier kurzfristig nichts bewegen, muss ich das Thema nach den Feiertagen rechtlich prüfen lassen, da hier meine Einahmequelle direkt ins Herz getroffen wurde.
Edit:
Ich habe soeben geprüft, wann ich das Update installiert habe, das mir diese Situation eingebrockt hat: mit Erscheinen von JTL-Wawi 1.11.5, also vor rund zwei Wochen. Das vorletzte Update erfolgte im Sommer 2025 und lief bei mir problemlos.
Fazit für mich: Zum Zeitpunkt meiner Installation war JTL dieser Fehler bereits bekannt, dennoch erfolgte keine Information oder Warnung. Wirtschaftlich und kommunikativ ist das nicht vertretbar. Niemand erwartet eine sofortige Fehlerbehebung, wohl aber Transparenz und klare Kommunikation.
In meinem konkreten Fall hätte ein einfacher Hinweis, Updates ab 1.11.1 vorerst nicht zu installieren, einen erheblichen finanziellen Schaden verhindert. Stattdessen wurde das Risiko vollständig auf die Anwender verlagert.
Zusätzlich entsteht der Eindruck, dass entweder die Tragweite dieses Fehlers – insbesondere für Nutzer, die mit globalen Feldern und Textbausteinen arbeiten – unterschätzt wird, oder dass entsprechende Tickets mit niedriger Priorität über längere Zeit unbearbeitet bleiben. Beides wäre problematisch.
Zuletzt bearbeitet:
@Manuel Pietzsch , könntest du da vielleicht Licht ins dunkle bringen? Für mich ist das unverständlich, warum das so lange dauert. Ich wüsste jetzt nicht, was da an einer Zeile Code so lange dauern könnte. Klar kenne ich den Quellcode nicht, aber wenn es länger dauert und einen Ratenschwanz hinterherzieht, dann doch bitte eben eine kurze Info, damit wir abgeholt werden.
Moin.
Zum Ersten - der Manuel ist seit 07.11.2025 nicht mehr im Forum gewesen.
Zum Zweiten - die Korrektur ist keine "eine Zeile", aber auch nicht aufwendig.
Zum Dritten das Ticket ist in Bearbeitung und wird mit 1.11.6 "ausgeliefert".
Viele Grüße, Ihr mvh-Team.
Zum Ersten - der Manuel ist seit 07.11.2025 nicht mehr im Forum gewesen.
Zum Zweiten - die Korrektur ist keine "eine Zeile", aber auch nicht aufwendig.
Zum Dritten das Ticket ist in Bearbeitung und wird mit 1.11.6 "ausgeliefert".
Viele Grüße, Ihr mvh-Team.
1. Welches konkrete Problem sollte gelöst werden?
- Gab es vor Version 1.11.x:
- Datenverlust?
- falsche Darstellung?
- Performance-Probleme?
- Beschwerden zur Mehrsprachigkeit?
2. Wer entscheidet, funktionierende Kernfunktionen zu ändern?
- Handelt es sich um:
- Bugfix?
- Feature-Erweiterung?
- internes Refactoring?
- „Code-Hygiene“?
3. Warum wurde ausgerechnet der Speicherpfad verändert?
Nachweislich:- Lesen funktioniert
- Datenmodell ist korrekt
- Nur das Schreiben ist defekt
4. Wie konnte ein solcher Fehler unentdeckt bleiben?
- Der Fehler ist:
- reproduzierbar
- versionsübergreifend
- geschäftskritisch
- Wenn ja: wie konnte der Fehler durchrutschen?
- Wenn nein: warum nicht bei einer Kernfunktion?
5. Warum zeigt das UI „Speichern erfolgreich“, obwohl nichts gespeichert wird?
Das ist kein kosmetischer Fehler.
6. Warum ist der Fehler mehrsprachig inkonsistent?
- Gleicher Textbaustein
- unterschiedliche Sprachen
- unterschiedliche Persistenz
7. Warum wurde der Fehler nicht sofort zurückgerollt?
- Meldungen existieren seit 1.11.1
- Fehler besteht in 1.11.5 weiterhin
8. Warum gibt es keine Warnung für Anwender?
- Keine Release Notes
- Keine Known Issues
- Keine Einschränkung dokumentiert
Moin. Zur Info.
Der Status für das Ticket https://issues.jtl-software.de/issues/WAWI-85988 steht seit Heute auf gelöst.
Ich warte auf Merge- und Build-Statusänderungen und vermutlich in 1.11.6 teste ich die Korrekturen.
Wer oder wann den Fehler gemacht hat und es nicht gemeldet/korrigiert/etc. hat - ist für mich damit irrelevant.
Nicht der erste und nicht der letzte Fehler in 1.11.
Der Status für das Ticket https://issues.jtl-software.de/issues/WAWI-85988 steht seit Heute auf gelöst.
Ich warte auf Merge- und Build-Statusänderungen und vermutlich in 1.11.6 teste ich die Korrekturen.
Wer oder wann den Fehler gemacht hat und es nicht gemeldet/korrigiert/etc. hat - ist für mich damit irrelevant.
Nicht der erste und nicht der letzte Fehler in 1.11.
@mvh:
Zum Verständnis aus kaufmännischer Sicht. Uns interessiert, wann der Stand wie vor 1.11.1 wiederhersgestellt wird oder ob wir hier noch weitere Wochen/Monate ausharren müssen. Eine Schadenersatzforderung ist auch nicht von heute auf morgen durchgesezt, aber angesichts des über zwei Monate bekannten Fehlers ist die Meldung des gelösten Tickets zwar schön, aber ohne eine konkrete Erklärung (mein Post #32) noch keine anfassbare Lösung. Ich gehe davon aus, daß der Hesteller eine Haftpflichtversiciherung hat und diese könnte oder sollte in einem Fall wie diesem durchaus in Anspruch genommen werden.
Du kannst Dir aussuchen, was für Dich das leichter zu ertragende Übel ist:
Mit den Fehlern leben oder JTL verklagen und in dem Moment die Kündigung auf dem Tisch haben.
Die Aussage „mit den Fehlern leben oder JTL verklagen und dann die Kündigung auf dem Tisch haben“ halte ich für problematisch – nicht nur im Ton, sondern auch in der Sache.
Aus kaufmännischer Sicht geht es hier nicht um „Fehler ertragen oder klagen“, sondern um einen seit über zwei Monaten bekannten, bestätigten und für viele produktiv schädlichen Bug, der nachweislich Umsätze, Abläufe und Vertrauen beeinträchtigt hat.
Wenn ein Hersteller einen solchen Fehler verursacht und dieser erst spät behoben wird, ist es völlig legitim, nach konkreten Zeitplänen, Transparenz und ggf. Kompensation zu fragen. Das ist normales unternehmerisches Handeln.
Die implizite Annahme, dass eine Schadenersatzforderung automatisch zu einer Kündigung führen müsse, wäre – sollte sie zutreffen – kein gutes Signal für das Verhältnis zwischen Hersteller und Kunden. Ein Unternehmen mit tausenden Geschäftskunden sollte Kritik, berechtigte Forderungen und auch rechtliche Klärungen professionell aushalten können. Niemand hier will „verklagen aus Prinzip“. Aber ebenso wenig kann man erwarten, dass betroffene Kunden monatelange Schäden einfach stillschweigend hinnehmen. Entscheidend ist daher nicht, wer den Fehler gemacht hat, sondern wann und wie verlässlich der Zustand vor 1.11.x wiederhergestellt wird – und wie JTL mit den Folgen für seine Kunden umgeht.
Wie lange seid ihr schon mit JTL unterwegs? Mir ist es unbegreiflich wie man ein produktives System einfach so umstellen kann. Es ist nun Mal so, dass die WAWI Versionen erst reifen müssen, wir haben keinen Kunden der die 1.11 im Einsatz hat, wir stellen die Kunden erst jetzt auf die 1.10.15.0 um.
Bei unseren größeren Kunden werden Testsysteme aufgebaut, die Zeiten von mal Mal eben ein Update sind schon lange vorbei.
@FOC Solutions
Danke für deine Rückmeldung. Ich verstehe den grundsätzlichen Ansatz mit Testsystemen und Reifeprozessen – und genau deshalb irritiert mich die Situation hier umso mehr.
Der konkret diskutierte Fehler ist seit Version 1.11.1 (18.10.2025) bekannt. In den darauffolgenden Versionen 1.11.2, 1.11.3, 1.11.4 sowie 1.11.5 war dieser Fehler weiterhin enthalten. Ich habe daher keine frisch veröffentlichte .0-Version installiert, sondern mit der 1.11.5 eine Version, in der der Fehler bereits seit mehreren Folgeversionen bekannt war – allerdings nicht mir als Anwender. Das halte ich für problematisch, da zwischen dem erstmaligen Bekanntwerden des Fehlers und meinem Update mehr als zwei Monate lagen, in denen aus meiner Sicht ausreichend Zeit gewesen wäre, betroffene Nutzer aktiv zu informieren oder zu warnen, insbesondere wenn Globale Textbausteine im Einsatz sind. Vor diesem Hintergrund gehe ich davon aus, dass JTL grundsätzlich Kenntnis darüber hat, welche Wawi-Versionen bei den Kunden im Einsatz sind, und dass die vorhandenen Kommunikationskanäle (z. B. regelmäßige Abrechnungs-E-Mails) grundsätzlich auch für entsprechende Hinweise genutzt werden könnten.
Wenn ein Fehler über mehr als zwei Monate und 5 Releases hinweg bestehen bleibt, stellt sich für mich die Frage, wie ein Anwender damit realistisch umgehen soll:
- Installiert man Updates, läuft man Gefahr, bekannte, aber nicht behobene Fehler zu übernehmen.
- Installiert man keine Updates, wird man früher oder später durch externe Abhängigkeiten (z. B. eBay-Schnittstellen, API-Änderungen, Abschaltungen alter Versionen) faktisch dazu gezwungen, doch zu aktualisieren.
Vor diesem Hintergrund fällt es mir schwer, die Verantwortung ausschließlich beim Anwender zu sehen. Gerade bei produktiven Systemen wäre aus meiner Sicht wichtig, dass bekannte, geschäftskritische Fehler entweder zeitnah behoben oder zumindest klar kommuniziert werden, inklusive belastbarer Aussagen, ab welcher Version sie tatsächlich gelöst sind.
Mich würde daher konkret interessieren, wie ihr diesen Zielkonflikt in der Praxis handhabt, wenn bekannte Fehler über mehrere Minor-Versionen hinweg bestehen bleiben und externe Plattformen parallel Aktualisierungen erzwingen und euch bewußt ist, daß ihr euch mit jedem Update ein weiteres Problem holt.
Über die grundsätzliche Situation bin ich völlig bei Dir, so einen Fehler auf die lange Bank zu schieben, ist mehr als unerfreulich.
Da wir primär B2B Kunden haben, benötigen diese oft nicht die aktuellen Releases. Es gibt natürlich Dinge die einen zwingen z.B. mit dem Zahlungsmodul vor WAWI 1.10.15.0, die einen Releasewechsel erzwingen. Aber auch in solchen Fällen entscheiden sich die Kunden oft gegen eine Releasewechsel und improvisieren eher drumherum. Ein großer Kunde von uns, der größte deutsche Shop für Feuerwerk, hätte sonst Mitte Dezember von der 1.9.8.0 wechseln müssen, nur dann hätte sein WMS mit rd. 50 Plätzen, nicht mehr funktioniert (bisher ungelöstes Performanceproblem ab WAWI 1.10). Das ist natürlich völlig ausgeschlossen.
So oder so ist es problematisch, die WAWI 1.11 scheint echte Bananenware zu sein. Auf die 1.10 konnte man auch erst mit der 1.10.14.3 gehen, zuvor dieser blöden Fehler mit der Ameise der eigentlich erst mit der 1.11 gefixt werden sollte.
JTL wird nicht umhinkommen, perspektivisch auch noch immer eine ältere Version zu supporten, sprich der WAWI 1.9.8.0 die Aktualisierungen, wie z.B. im Zahlungsmodul, zukommen zu lassen.
Im Bereich der SCX-Schnittstellen wurde ja schon eine gewisse Unabhängigkeit von der WAWI Version geschaffen. Das wird perspektivisch der Weg sein.