Neu Unzufriedenheit mit dem JTL-Support

[dc-nico]

Also da wäre ich mir nicht so sicher mit dem Lister 2.0, denn für 1 % an Nutzern, hätte JTL sich nicht so einen Aufwand gemacht.
Der Lister 2.0 hat eine großen Umfang an Funktionen, welche alle mit Amazon abgestimmt werden müssen.
Das macht man nicht für 1% der Nutzer.

Aber ich glaube wir haben uns hier etwas falsch verstanden, es soll die komplette Vorgehensweise bei der Fehler Behebung ändern und das wird sich auch noch ein wenig hinauszögern.
Ich habe in Vergangenheit sehr viele Probleme gemeldet, welche bis heute nicht behoben wurden und daher geht es sicher nicht nur um den Lister.
Wir werden sehen was sich tut.

 

[SebiW]

Naja, JTL hat auch ein Riesensystem für produzierendes Gewerbe (das wir als produzierendes Gewerbe schon alleine aufgrund der Preisstruktur ignorieren), hatte mal nenn kompletten Servicedesk gebaut (und mitterweile wieder eingestampft), entwickelt seit mehr als 5 Jahren an BI rum, hat ein eigenes Kassensystem aus dem Boden gestampft (wollen wir wetten wie hoch der Prozentsatz der User da ist?) etc etc

Wieviel davon nutzt Du? Dürfte alles größer und deutlich aufwändiger sein als der Lister 2.0.

Dass JTL etwas mit viel Aufwand betreibt heisst keineswegs, dass es in der breiten Anwendermasse in Verwendung wäre

JTL hat offensichtlich in allen Bereichen, beginnend beim Support über die Entwicklung bis hin zur QC zu wenig Personal für die Größe des Rades, dass sie drehen. Ich danke Dir, und das meine ich ehrlich, dass Du bereit bist hier zusätzlich für uns alle Kosten zu tragen. Aber ich glaube absolut 0,0 daran, dass das irgendeine Änderung bei JTL auslösen wird. Tatsächlich ermöglichst Du damit der Firma sogar eher noch, weiteres Personal einzusparen. Du übernimmst ja den Vorsupport.
Ist wie mit den Selbstbedienungskassen. Am Ende übernimmt der Kunde die Arbeit und der Händler spart nenn weitere Kassierer weg.

 

[frankell]

Das kommt natürlich immer auf den Umfang der Software an. Aber bei sowas umfangreichen wie der Wawi...

..., die es nicht erst seit gestern gibt. Insofern viel Zeit für den Aufbau einer umfassenden automatisierten Testumgebung.

Ich habe mal gelernt, an möglichst alles zu denken. Daher kommt mir der Gedanke, sowohl mit direktem Import als auch mit einem Testlauf davor (ohne Schließen der Ameise dazwischen) zu testen, irgendwie so gar nicht weit hergeholt vor. 😊

Abgesehen davon gibt es noch diverse andere Beispiele, die aus Deiner Sicht passender sein mögen, so dass man am Ende zur selben Schlussfolgerung kommt.

 

[forumjtlolshopag]

Schlechtes Beispiel. Das ist kein kritischer Bug, weil ein simpler Workaround existiert. Ja, war lästig, die Ameise zweimal aufzurufen, das erste Mal für den Testlauf, dann für den eigentlichen Import, aber dass ein Bug mit existierendem Workaround nicht höchste Priorität hat, ist logisch. Den hätte ich persönlich auch nicht priorisiert behandelt. Da geht jeder Importfehler der Ameise vor.

Sehe ich anders. Das ist eine Kernfunktion, die in allen früheren Versionen problemlos funktioniert hat und daher zeitnah korrigiert werden sollte, zumal der Aufwand dafür überschaubar ist.
Eine neue Version wurde veröffentlicht, ohne dass glaub im Changelog erwähnt wurde, dass an der Ameise etwas geändert wurde. Trotzdem ist genau an dieser Stelle ein Fehler entstanden. Wenn ein Entwickler am Trockenlauf etwas umprogrammiert, muss dieser Vorgang im Changelog dokumentiert und anschließend gründlich getestet werden, entweder automatisiert oder manuell.
Der Ameisen-Fehler ist kein Einzelfall. Es gibt viele ähnliche Probleme, die im Laufe der Jahre aufgetreten sind und bei denen man sich fragt, wie so etwas passieren kann und warum nach Änderungen nicht sauber intern getestet wird. Solche „Minibugs“ könnten problemlos in der nächsten Unterversion behoben werden, bleiben aber oft monatelang bestehen. Irgendwann werden sie dann doch korrigiert, allerdings erst mit in der nächsten Majorversion.

Als JTL-Wawi Nutzer lernt man relativ schnell, die ersten Release Builds der neuen Majorversion besser zu überspringen, um sich nicht noch mehr Baustellen einzuhandeln. Und dann wundert sich JTL und fragt uns Nutzer, warum wir nicht immer sofort auf die neuste Version gehen.

Ich habe grundsätzlich kein Problem damit, dass Fehler passieren. Das eigentliche Problem sehe ich darin, dass solche kleinen Fehler nicht zeitnah im nächsten Release-Build korrigiert werden.

 

[Enrico W.]

Eine kleine Korrektur:
https://issues.jtl-software.de/issues/WAWI-81299 ist seit der 1.11.0 abgeschlossen und steht auch im Changelog:
https://www.jtl-software.com/de/war...ngelog?fromVersion=1.10.10.3&toVersion=1.11.0

 

[hula1499]

@dc-nico
Du solltest doch jetzt schon knapp 1 Monat deinen "think tank" mit JTL haben, wie läufts denn so?
Sind eure ersten Erfolge diesbezüglich schon irgendwo dokumentiert?

 

[dc-nico]

Guten Morgen,

es hieß ja, dass zuerst die Back Friday Tage abgearbeitet werden müssten, um dann das Ganze anzugehen.
Da ich mich überhaupt nicht mit solche Aktionen beschäftige, kann ich auch nicht sagen, wann diese Tage überwunden sind.
Es ist aber auch sicher, dass ich für eine Optimierung des Supportsystems stehe und sicher nicht nur für einzelne Bugs einsetze.
Frage gleich ein mal nach, was nun angesetzt ist.

Gruß
NICO