Bleibt bei 1.5!

[SebiW]

Ich sag mal so, wenn es denn eine vernünftig funktionierende Version nach 1.5 geben würde, wäre ich deiner Meinung. Aber es gibt ja einen Grund warum noch diverse Firmen mit der 1.5 unterwegs sind.

Das größte Problem dürfte imho der massive Bruch von 1.5 auf 1.6 sein. Die 1.7 auf der wir sind funktioniert problemlos. Der Weg da hin ist das Drama.

Und es gibt auch noch genug Firmen auf 1.4, 1.3 und sogar noch mit 0.X er Wawis. Wenn man keine Shopanbindung und keine Marktplätze braucht spricht da auch wenig dagegen.
Man wird halt dauerhaft nicht erwarten können, das JTL Versionen, die seit Jahren EOL sind, weiter mit Fixes versorgt.
Die 1.5 ist tot. Die 1.6 auch. Und die 1.7 ebenso. Irgendwann nächstes Jahr kommen 1.9 und dann steht die große 2 bevor.
Wenn man externe Anbindungen braucht deren Updatezyklen man nicht kontrollieren kann (Ama, Ebay etc), dann wird man um ein Update auf 1.7 + mittelfristig nicht mehr drumrum kommen.
Genau das hat der aktuelle Vorfall ja gezeigt. Man will defintiv nicht auf einer Version sitzen, die in so einer Situation keine schnelle Hilfe kriegt.

 

[frankel]

Wir können dem Ratschlag, nicht auf 1.6 zu wechseln, nur nachdrücklich zustimmen! Wir arbeiten seit ca. 15 Jahren mit der Wawi, aber so ein Katastrophenupdate haben wir noch nicht erlebt. Es wirkt, als säße bei den Entwicklern ein neues Team, das von der praktischen Anwendung nicht die geringste Ahnung hat.
Wir würden JTL nach langer Zeit nun gerne verlassen, scheuen aber den Aufwand. Insofern leben wir im Moment mit einer sehr unbefriedigenden Situation. Es war lange Zeit sehr angenehm, mit der Wawi zu arbeiten. Das kommt wohl nicht wieder.

 

[recent.digital]

das ist schon eine große Umstellung, das ist richtig.
Was stört dich besonders?

Vielleicht dürfte das ein oder andere Thema mit der 1.7/1.8 erledigt sein.

 

[css-umsetzung]

So lange dieses Thema: https://issues.jtl-software.de/issues/WAWI-72420 nicht behoben ist (und das ist nun schon recht lange ein Thema)
kann ich niemanden dazu raten diesen Schritt zu gehen.

Der Fehler ist recht drastisch. Pro Abgleich muss 1x der Server neu gebootet werden. Auch das hilft nicht immer. Das Problem tritt ab Version 1.7.10 ca. auf.

Auch wenn es eventuell eine begrenzte Anzahl an Shop Besitzer gibt, ich werde das Risiko nicht eingehen, das einem meiner Kunden anzutun.

Ich hoffe mal das es bis Juni erledigt ist, sonst wird es lustig.
Ich weiß gar nicht, ist das Thema mit den ständigen Abstürzen denn schon erledigt?

 

[frankel]

Wir sind mal angefangen, eine Liste zu erstellen, um diese bei JTL einzureichen. Wir mussten irgendwann abbrechen, da die Liste zu lang wurde. Von daher hätten wir einfach eine Rückkehr zu 1.5 empfohlen.
Beispiele: Packliste (wir haben immerhin eine Behelfsliste mit freundlicher Unterstützung von Manuel anlegen können, ist aber nicht das gleiche), Gutschriften können nicht für Einzelartikel sondern nur für eine VE angelegt werden.
Das ist komplett praxisfremd. Zahlungen oder Erstattungen müssen entweder bei Aufträgen oder bei Rechnungen eingetragen werden, je nachdem zu welchem Zeitpunkt sie eingegangen sind. Gleiches gilt für Rückzahlungen, je nachdem ob Sie als Gutschrift oder als einfache Überzahlungen erstattet werden. Es kommt dann vor, dass für den selben Kunden unterschiedliche Darstellungen sind. So kann in einer Darstellung der Auftrag als bezahlt und in der anderen ein Rechnungsbetrag offen stehen. Das ist einfach totales Chaos, das JTL da angerichtet hat. Je mehr JTL glaubt, Vorschriften zu machen, wie etwas einzutragen ist, desto unbefriedigender wird das für die Anwender, weil JTL offensichtlich die Praxis nicht kennt.

 

[MichaelH]

Packliste - sofern du die Lagerpackliste meinst, die gibt es nun wieder in der 1.8.

 

[Enrico W.]

@frankel Das Beste ist: Macht für Bugs einzelne Tickets auf. So ein Sammelthread wie dieser hier oder ein Sammelticket sind absolut kontraproduktiv. Das kann man weder einzelnen POs noch einzelnen Entwicklern zuweisen.
Die Zahlungen können immer einem Auftrag zugeordnet werden, wenn es eine Rechnung gibt, dann kann die Zahlung der Rechnung oder dem Auftrag zugeordnet werden.
Wenn Du meinst, dass JTL die Praxis nicht kennt: Sag mir, in welchem Bereich dein größter Painpoint liegt und ich sehe zu, dass Du dem PO Deine Praxis aufzeigen kannst.
Aber berücksichtige bitte den Stand der 1.8. Es bringt nichts, über mittlerweile veraltete Versionen zu reden (und in diesem Thread gehts um die 1.6!)

 

[BeniF]

@frankel Das Beste ist: Macht für Bugs einzelne Tickets auf. So ein Sammelthread wie dieser hier oder ein Sammelticket sind absolut kontraproduktiv. Das kann man weder einzelnen POs noch einzelnen Entwicklern zuweisen.
Die Zahlungen können immer einem Auftrag zugeordnet werden, wenn es eine Rechnung gibt, dann kann die Zahlung der Rechnung oder dem Auftrag zugeordnet werden.
Wenn Du meinst, dass JTL die Praxis nicht kennt: Sag mir, in welchem Bereich dein größter Painpoint liegt und ich sehe zu, dass Du dem PO Deine Praxis aufzeigen kannst.
Aber berücksichtige bitte den Stand der 1.8. Es bringt nichts, über mittlerweile veraltete Versionen zu reden (und in diesem Thread gehts um die 1.6!)

Automatische Rücküberweisung von Retouren???? KANN JTL NICHT Die Tickets dazu sind JAHRE alt !

 

[jtldudel]

Kann die 1.5 das?

 

[mvh]

Kann die 1.5 das?

Wir wissen nicht, was die Vorredner meinen.
Hier was wir machen:
Wir nutzen 1.7/1.8, erstellen Gutschriften in den Retouren
und lassen sie über das Zahlungsmodul nach TAN-Freigabe zurücküberweisen.
Wir sind soweit damit zufrieden.
Viele Grüße, Ihr MVH-Team

 

[jtldudel]

Wir wissen nicht, was die Vorredner meinen.
Hier was wir machen:
Wir nutzen 1.7/1.8, erstellen Gutschriften in den Retouren
und lassen sie über das Zahlungsmodul nach TAN-Freigabe zurücküberweisen.
Wir sind soweit damit zufrieden.
Viele Grüße, Ihr MVH-Team

War rhetorisch, denke der Vorredner will den Vorgang automatisieren (weiß nicht, Workflows die dann die Ausgangszahlung automatisch erstellen und senden denke ich Mal).

Ist aber in 1.5 auch nicht möglich, ist kein Grund bei der 1.5 zu bleiben.

 

[mvh]

War rhetorisch, denke der Vorredner will den Vorgang automatisieren (weiß nicht, Workflows die dann die Ausgangszahlung automatisch erstellen und senden denke ich Mal).

Ist aber in 1.5 auch nicht möglich, ist kein Grund bei der 1.5 zu bleiben.

Ja, vermutlich das: https://issues.jtl-software.de/issues/WAWI-31427
ist aber auch kein Grund nicht zu 1.8 zu wechseln,
wie Du richtig schreibst - in 1.5 wird es nicht mehr umgesetzt.

 

[Verkäuferlein]

Wir wissen nicht, was die Vorredner meinen.
Hier was wir machen:
Wir nutzen 1.7/1.8, erstellen Gutschriften in den Retouren
und lassen sie über das Zahlungsmodul nach TAN-Freigabe zurücküberweisen.
Wir sind soweit damit zufrieden.
Viele Grüße, Ihr MVH-Team

Habt Ihr denn von jedem Kunden die Bankverbindung oder lasst Euch die bei der Retoure beilegen?

Und was macht Ihr bei Zahlungsanbietern, die nur Erstattungen über ihr System zulassen?

Aber wir ihr schon schreibt, ist das ja leider ein fehlender Grund, der zum Wechsel von der 1.5 weg verleitet und kein Grund bei der 1.5 zu bleiben.

Wir sind im Moment auch bei der 1.8 und ich glaube in der 1.5 würde ich mich nicht mehr zurechtfinden.
Und besonders gefällt mir mittlerweile die Erstellung von Variantenartikeln (Varkombis), da hat sich - finde ich - total viel getan.

 

[mvh]

Habt Ihr denn von jedem Kunden die Bankverbindung oder lasst Euch die bei der Retoure beilegen?

Und was macht Ihr bei Zahlungsanbietern, die nur Erstattungen über ihr System zulassen?

Aber wir ihr schon schreibt, ist das ja leider ein fehlender Grund, der zum Wechsel von der 1.5 weg verleitet und kein Grund bei der 1.5 zu bleiben.

Wir sind im Moment auch bei der 1.8 und ich glaube in der 1.5 würde ich mich nicht mehr zurechtfinden.
Und besonders gefällt mir mittlerweile die Erstellung von Variantenartikeln (Varkombis), da hat sich - finde ich - total viel getan.

Moin. Wir nutzen PayPal, AmazonPay und Klarna und über Zahlungsmodul von JTL können wir jeder Zeit eine Rückbuchung tätigen, zumindest von diesen Anbietern. Wir haben unsere Umstellung von 1.5 längst hinter uns und bereuen es nicht. Manches ist einfacher geworden, manches nicht, mal sehen wohin die Reise uns bringt.

 

[frankel]

@frankel Das Beste ist: Macht für Bugs einzelne Tickets auf. So ein Sammelthread wie dieser hier oder ein Sammelticket sind absolut kontraproduktiv. Das kann man weder einzelnen POs noch einzelnen Entwicklern zuweisen.
Die Zahlungen können immer einem Auftrag zugeordnet werden, wenn es eine Rechnung gibt, dann kann die Zahlung der Rechnung oder dem Auftrag zugeordnet werden.
Wenn Du meinst, dass JTL die Praxis nicht kennt: Sag mir, in welchem Bereich dein größter Painpoint liegt und ich sehe zu, dass Du dem PO Deine Praxis aufzeigen kannst.
Aber berücksichtige bitte den Stand der 1.8. Es bringt nichts, über mittlerweile veraltete Versionen zu reden (und in diesem Thread gehts um die 1.6!)

@Enrico
Diese Threat bringt die Unzufriedenheit diverser Nutzer mit unsinnigen Änderungen, die die Usability erheblich einschränken, zum Ausdruck. So ein Threat macht absolut Sinn. Hätten wir so etwas vorher gelesen, wären wir bei der 1.5 geblieben und hätten ein wesentlich entspannteres Leben. Es geht auch nicht um Bugs, sondern um Änderungen, die dem User das Leben unnötig schwer machen.
Von daher kannst Du gerne auf Grundlage der 1.8 diskutieren. Wir reden hier über Änderungen der 1.6. Da wir uns seit nunmehr einem Jahr erheblichste Probleme mit Updates sowohl bei der Wawi, als auch beim Shop, incl. erheblicher Umsatzeinbußen, eingehandelt haben, werden wir nur noch updaten, wenn absolut sichergestellt ist, dass wir uns nicht nochmehr Probleme einhandeln.
Du fragst nach einem praxisfremden Ärgernis bei der Wawi? Ein Beispiel: Bei Auftragserstellung, Angebotsanlage und Rechnungskorrektur können Stückzahlen nicht frei eingegeben, sondern sind an Mindestabnahmemengen bzw. Abnahmeintervalle gebunden. Das ist nicht nur unsinnig, sondern auch unnötig. Bestellt ein Kunde 10 Halstücher (da VE = 10) und reklamiert eins davon, können wir keine Rechnungskorrektur erstellen, weil Wawi nur Eingaben 10, 20, 30… akzeptiert. Wir müssen also nun die Mindestabnahmemenge erst manuell auf 1 ändern, bevor wir eine Rechnungskorrektur erstellen können. Damit der Artikel nicht während der Bearbeitung mit VE=1 bestellt wird, müssen wir ihn erstmal aus dem Shop nehmen. Nach erstellter Rechnungskorrektur müssen dann Mindestabnahmemengen und Intervall wieder auf 10 gestellt werden, bevor der Artikel wieder online gestellt werden kann. Völlig sinnbefreit.
Anderes, schon häufig genanntes Beispiel: Nach der Erstellung der Rechnung stellt sich heraus, dass ein Tippfehler in der Lieferadresse oder in der Umsatzsteuer ID ist. Das kann nun nicht mehr geändert werden. Also muss eine Rechnungskorrektur und sodann eine neue Rechnung erstellt werden. Überflüssig und ärgerlich. Hierzu habe ich dann im Forum rechtliche Behauptungen seitens JTL gelesen, die zum fremdschämen falsch waren.
Das sollte erstmal reichen. Ich habe ja oben auch schon Beispiele gebracht.
Viele Grüße
Frank

 

[jtldudel]

@Enrico
Diese Threat bringt die Unzufriedenheit diverser Nutzer mit unsinnigen Änderungen, die die Usability erheblich einschränken, zum Ausdruck. So ein Threat macht absolut Sinn. Hätten wir so etwas vorher gelesen, wären wir bei der 1.5 geblieben und hätten ein wesentlich entspannteres Leben. Es geht auch nicht um Bugs, sondern um Änderungen, die dem User das Leben unnötig schwer machen.
Von daher kannst Du gerne auf Grundlage der 1.8 diskutieren. Wir reden hier über Änderungen der 1.6. Da wir uns seit nunmehr einem Jahr erheblichste Probleme mit Updates sowohl bei der Wawi, als auch beim Shop, incl. erheblicher Umsatzeinbußen, eingehandelt haben, werden wir nur noch updaten, wenn absolut sichergestellt ist, dass wir uns nicht nochmehr Probleme einhandeln.
Du fragst nach einem praxisfremden Ärgernis bei der Wawi? Ein Beispiel: Bei Auftragserstellung, Angebotsanlage und Rechnungskorrektur können Stückzahlen nicht frei eingegeben, sondern sind an Mindestabnahmemengen bzw. Abnahmeintervalle gebunden. Das ist nicht nur unsinnig, sondern auch unnötig. Bestellt ein Kunde 10 Halstücher (da VE = 10) und reklamiert eins davon, können wir keine Rechnungskorrektur erstellen, weil Wawi nur Eingaben 10, 20, 30… akzeptiert. Wir müssen also nun die Mindestabnahmemenge erst manuell auf 1 ändern, bevor wir eine Rechnungskorrektur erstellen können. Damit der Artikel nicht während der Bearbeitung mit VE=1 bestellt wird, müssen wir ihn erstmal aus dem Shop nehmen. Nach erstellter Rechnungskorrektur müssen dann Mindestabnahmemengen und Intervall wieder auf 10 gestellt werden, bevor der Artikel wieder online gestellt werden kann. Völlig sinnbefreit.
Anderes, schon häufig genanntes Beispiel: Nach der Erstellung der Rechnung stellt sich heraus, dass ein Tippfehler in der Lieferadresse oder in der Umsatzsteuer ID ist. Das kann nun nicht mehr geändert werden. Also muss eine Rechnungskorrektur und sodann eine neue Rechnung erstellt werden. Überflüssig und ärgerlich. Hierzu habe ich dann im Forum rechtliche Behauptungen seitens JTL gelesen, die zum fremdschämen falsch waren.
Das sollte erstmal reichen. Ich habe ja oben auch schon Beispiele gebracht.
Viele Grüße
Frank

Das mit der Mindestmenge und Abnahme Intervall in der Rechnungskorrektur ist interessant, ich konnte es gerade in 1.8.11.2 nachstellen, ABER wenn ich aus die RK direkt aus einer Retoure erstelle, kann ich auch einzelne Mengen erfassen. Die RK muss dann aber im Wert dort gemindert werden, da hier immer die gesamte abgenommen Menge gutgeschrieben werden soll, auch wenn nur ein Teil davon zurück kommt. In der RK steht dann aber tatsächlich eine Menge von 1.

@frankel hattet ihr da auch Mal ein Ticket zu eröffnet?

 

[Markus Hütz]

Nach der Erstellung der Rechnung stellt sich heraus, dass ein Tippfehler in der Lieferadresse oder in der Umsatzsteuer ID ist. Das kann nun nicht mehr geändert werden. Also muss eine Rechnungskorrektur und sodann eine neue Rechnung erstellt werden. Überflüssig und ärgerlich. Hierzu habe ich dann im Forum rechtliche Behauptungen seitens JTL gelesen, die zum fremdschämen falsch waren.

Guten Morgen,

mich würden hier mal die "zum fremdschämenden rechtlichen Behauptungen seitens JTL" interessieren?

Das Beispiel mit der Lieferadresse und Umsatzsteuer-ID finde ich gut: BEIDE Daten haben unter Umständen einen Einfluss auf die Mehrwertsteuer. Am Ende hat man zwei Rechnungen versendet, beide mit gleicher Rechnungsnummer, beide mit unterschiedlichen steuerlichen Werten.

Ist der folgende Prozess wirklich so schlimm, dass man lieber Rechnungen bearbeiten möchte und sich damit evtl. Ärger einhandelt?

Rechnung > Rechtsklick > Stornieren > Neu ausstellen > Storno begründen > "genau die Daten ändern die du ändern möchtest" > Speichern und Festschreiben

Um buchhalterisch korrekt zu sein hat man (aus meiner Sicht) einen Mehraufwand von einem Rechtsklick und der Auswahl eines Grundes.


Gruß,
Markus

 

[Enrico W.]

@frankel Ich möchte kurz darlegen, warum ich mit diesen Sammelthreads ein Problem habe.
Ja, Ärger ist verständlich und Kritik wichtig. Aber: Zum einen redet ihr hier über eine Version, die mittlerweile als veraltet zu betrachten ist. Es wird in der 1.6 keine Änderungen geben. Ihr berücksichtigt nicht, dass es möglicherweise aufgrund der Rückmeldungen bereits Änderungen in den aktuellen Versionen gibt. Diskussionen sind schwer bis unmöglich mitzuverfolgen. Threads oder Tickets, die sich auf 1, 2 Themen fokussieren, sind da wesentlich besser mitzuverfolgen.
Was wäre also die Lösung?
Für Bugs einzelne Tickets. Warum? Die Themen/Bereiche liegen ggf. in unterschiedlichen Fachbereichen und müssen von verschiedenen Teams umgesetzt werden. Aber auch hier muss vorab geprüft werden, ob der Bug in der aktuellen Version überhaupt noch vorhanden ist.
Für Kritik/Änderungswünsche einzelne Threads/Tickets. Warum? Weil ein solcher Sammelthread wie oben bereits gesagt, nicht geeignet ist, um eine sachliche Diskussion zu führen. Das zeigt die Erfahrung zur Genüge.
Dass ihr nur updatet wenn ihr sicher seid - das ist richtig. Das ist wichtig. Und das ist verständlich. Aber dann wieder zu einer mittlerweile auch veralteten Version? Baut euch ein mal ein Testsystem. Spielt dort die Datenbanksicherung ein und prüft Eure Vorgänge mit der aktuellen Version (ohne etwas zu versenden oder abzugleichen!). Und entscheidet dann.
Die 1.5 ist abgeschlossen, der Support dafür wird eingestellt. Daran gibt es keine Änderungen mehr. Auch an der 1.6 wird es keine Änderungen mehr geben, es sei denn, es ist ein wirklich dringender Hotfix notwendig. Und selbst dann wird diese Version nur den Hotfix als Änderung beinhalten. Beides ist aber mit Blick auf das Alter der Version relativ unwahrscheinlich. Auch wird früher oder später für die 1.6 der Support eingestellt werden. Um mit einer Metapher zu sprechen: Ihr wollt von einem toten Pferd eventuell absteigen, um auf das nächste aufzusatteln, welches kurz vor dem Schlachthof steht und dann noch beschweren, dass dieser Gaul keine Zähne mehr hat.
Daher noch mal mein dringender Rat: Schaut euch die aktuelle Version an. Prüft, ob diese für Euch Probleme bereithält. Prüft, ob sich darin bereits bestehende Probleme erledigt haben. Und gibt es noch Wünsche/Probleme in dieser Version, dann tragt diese an uns heran.

 

[SebiW]

Hallo @Enrico W. , hier muss ich Dir in gewissem Umfang widersprechen. Du siehst solche Posts hier zu einseitig aus der Sicht Eures Kundensupports. Threads wie dieser sind aber nur sehr eingeschränkt direkt an Euch gerichtet.
Das Forum dient auch und gerade der Kommunikation zwischen Euren Usern. Und an diese Mituser richtet sich auch dieser Post. Es soll keine einzelnen Fehler an Euch kommunizieren. Dafür wäre er, wie Du schreibst, auch ungeeignet.

Und gelegentlich braucht es dann auch solche Sammelthreads um der Stimmung innerhalb der Community Ausdruck zu verleihen. Dafür sind einzelne Fehlerthreads widerum sehr ungeeignet. Insofern solltet Ihr von JTL Seite Threads wie diesen auch als das verstehen was sie sind: Ausdrücke der Stimmungslage innerhalb eines Teiles Eurer Userschaft, nicht bezogen auf ein spezifisches Problem sondern auf den Gesamtzustand. Ob und inwieweit das für Euch dann intern relevant ist steht auf einem anderen Blatt.

Wir sind mittlerweile auf der letzten 1.17er. Wir werden mittelfristig auf die 1.18er wechseln sobald unsere aktuellen Baustellen (Shopumstieg, Umstellung unserer CMS Software) erledigt sind. Allerdings bleibe ich dabei: Das überschreiten des Rubicons von 1.5 zu 1.6 war der größte Bruch, den wir mit JTL seit der 1.0 erlebt haben. Das muss man wissen wenn man diesen Umstieg durchführt. Es geht weniger darum, was sich in einzelnen Prozessen geändert hat sondern vielmehr darum, in wievielen Prozessen sich Sachen geändert haben, zum Guten wie zum Schlechten. Das muss man als User wissen und wisst Ihr bei JTL ja auch, nicht umsonst habt Ihr mehrfach kommuniziert, dass Majors in Zukunft kleiner und kürzer getaktet kommen werden.

Und genau für diese Art der Kommunikation ist ein Thread wie der hier optimal. Die relativ überschaubare Menge an Reaktionen zeigt aber ja auch, dass das Problem für viele nicht übermässig groß ist oder durch kompetente Servicepartner abgefedert wurde. Dass es aber ein Thema war und ist zeigen ja auch schon Umfragen wie von Euch selbst: https://forum.jtl-software.de/threads/was-haelt-dich-noch-auf-der-1-5.203410/

 

[Enrico W.]

Ich kann euch da durchaus verstehen. Aber was sagt diese Stimmungslage aus, wenn sie auf einem Gaul herumreitet, der schon längst tot ist? Da wird sich beschwert, dass etwas nicht funktioniert. Wenn das berechtigt ist, dann bin ich der Letzte, der dagegen was sagt. Aber OB es berechtigt ist kann man nicht sagen, wenn man nicht die aktuellen Versionen betrachtet.