Neu Was hält dich noch auf der 1.5?

DITH-Shop

Sehr aktives Mitglied
8. Juli 2013
2.722
175
Ich kann kein Update von 1.5.x auf neuere Versionen machen, weil ich viel zu viele eigene Tools bauen musste, für drigend erforderliche Funktionen die in der Wawi einfach seit Jahren ständig angefragt werden, aber nie umgesetzt wurden.
Bspw. Automatische Preisberechnung anhand von Regeln.
Diese (und viele andere) Funktion läuft bei mir mit der 1.5.55 problemlos - sinnvolle Neuerungen kann ich in den Dokumentationen nicht finden.

WENN es ein Script gäbe um die Datenbank auf Update-Fähigkeit zu testen BEVOR man das Update tatsächlich durchführt, KÖNNTE ich mich ggf damit anfreunden.
Aber ich möchte kein Update durchführen um dann 10 Mal zu lesen das die eine oder andere Tabelle nicht geupdatet werden kann weil View xyz darauf zugreift. - und dann immer wieder tagelang Backups einzuspielen.

Allerdings muss ich gestehen das ich mit der direkten Anbindung an Marktplätze endlich von UNICORN2 wegkommen könnte, und das als einzigen Grund ansehe tatsächlich ein Update in Betracht zu ziehen.
UNICORN2 ist aktuell leider nicht fähig ohne Probleme meine Angebote abzuarbeiten und die Unterstützung dort ist auch nicht mehr wie früher.
 

gnarx

Sehr aktives Mitglied
18. Januar 2018
3.848
530
Es gibt ja eine Seite von JTL wo genau beschrieben wird welche DB Felder weech sind bzw. anders heißen. Reicht das nicht?
 

mh1

Sehr aktives Mitglied
4. Oktober 2020
1.516
454
WENN es ein Script gäbe um die Datenbank auf Update-Fähigkeit zu testen BEVOR man das Update tatsächlich durchführt, KÖNNTE ich mich ggf damit anfreunden.
Ein Update sollte man auf jeden Fall erstmal auf einem Testsystem durchlaufen lassen.
Also auf irgendeinen ausgemusterten PC/Laptop einen SQL-Server installieren. Dort ein aktuelles Backup der Produktivdatenbank einspielen und dann ein Update machen.
Das kann ein uralter und langsamer PC sein, aber nur durch das echte Update kann man sehen, ob es durchläft. Jedes Skript, dass ein Update nur simuliert, aber doch nicht wirklich durchführt ist Käse.
Nebenbei übt man sich selbst darin, ein Backup wiederherzustellen und vor allem prüft man damit auch das erstellte Backup (was ein essentiell wichtiger Bestandteil jeder Backup-Strategie ist).
 

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
7.125
1.875
Berlin

301Moved

Sehr aktives Mitglied
19. Juli 2013
930
188
Das Problem ist auch in vielen Fällen, dass die WaWi viele Möglichkeiten bietet, eigenen Funktionien zu basteln, Workflows zur Funktionalitätsergänzung zu bauen, Formulare zu ergänzen und das auch ja empfohlen wird, bzw. diese Funktionen dafür ja extra in die WaWi gebaut wurden mit der Zeit.

Leider aber stellt man eben nach jedem Update fest, dass nicht nur Core-Funktionalitäten, die vorher noch gingen, nicht mehr gehen oder mal wieder nicht gehen, sondern auch viele der eigenen "Funktionen". Dann gibt es auf einmal Variablen nicht mehr, dann gibt es dafür neue, die aber nicht vollständig sind, oder oder...

Eine Funktion, die vor einem Update prüft, was genutzt wird und was davon nicht mehr unterstützt wird, wäre ein Traum. Noch traumhafter wäre "Bypass/Plugin/Child-Funktionen" bpsw. für Formulare. Core-Formular, Änderungen können wie im Shop an Templatepositionen eingefügt werden. Generell wäre es geil, wenn die WaWi modularisiert geupdatet werden könnte. Fester Core. Dann per "Plugins/Addons" sowas wie Servicedesk, Produktion, oder oder... manchmal updatet man nur, weil man einen bestimmten Fehler weghaben will und dann holt man sich, weil gleich so viel bearbeitet wurde, viele neue Fehler in anderen Bereichen rein.

Sinnvoll wäre weiter, wenn der Issue-Tracker auch wirklich alle Tickets anzeigt und wenn man noch besser filtern könnte. Denn wenn die ganzen unzähligen, unsichtbaren (Entwickler-)Tickets nicht als Fehler auffindbar sind, bringt das ganze nur halbwegs was, aber vor allem keine sinnvolle Orientierung mehr.

Für ein Projekt ging es auch auf die 1.6, weil eine Funktion genutzt werden sollte (die auch immer noch im beta ist), dafür gingen dann andere Dinge nicht. Update: Fehler behoben, gingen wieder andere Dinge nicht. Uswusf. Update auf 1.7, weil zumindest schneller Updates in der beta kamen und der Issue-Tracker kaum noch was aufgeführt hatte (joar, war halt nur nicht sichtbar), also das 1.6 Spielchen von vorne.

Man testest Updates mit wirklich viel Zeit, aber gerade produktive Features kann man eben auch nicht immer komplett testen. Und dann steht man wieder da. Baut eine "Umleitung", die dann irgendwann auch wieder nicht geht und dann geht das Spielchen von vorn los.
 
  • Gefällt mir
Reaktionen: Neumann

gnarx

Sehr aktives Mitglied
18. Januar 2018
3.848
530
Eine Funktion, die vor einem Update prüft, was genutzt wird und was davon nicht mehr unterstützt wird, wäre ein Traum.
So etwas in der Art ist ja seitens JTL geplant. Wir müssen nur Szenarien zur Verfügung stellen die das System bei JTL prüfen soll. Also nicht den normalen Kram.
Wir haben denen schon was zur Verfügung gestellt was JTL u.U. in der Richtung hilft.
 

apalusa

Sehr aktives Mitglied
22. Oktober 2018
258
72
aber immer eine Firma zu kontaktieren um Portogebühren zu ändern, kann ja nicht Sinn von JTL sein.
Geändert in der Wawi habe ich sie, im Shop gehts bloß nicht, trotz kompletten Abgleich
Naja den Aspekt mit den Versandkosten kann ich aber nicht nachvollziehen. EInfach im Shop Backend einloggen und dann "Versand -> Versandarten" und bei der entsprechenden Versandart die Kosten anpassen. Dass der Shop nicht automatisch die Versandarten aus der Wawi übernimmt macht schon Sinn, da hier ja unter Umständen etliche Versandarten existieren für Amazon, eBay, etc. die nichts im Shop verloren haben.

aber hier fehlt die (abweichende) Lieferadresse und die Auftragsnummer, 2 essentielle Informationen.

Gibt es irgendwo eine Doku, einen Link oder kann mir jemand sagen wie man diese Infos wieder auf die Rechnung bekommt?
Ich weiß nicht welche Version ihr habt, aber in der 1.6.48.0 gibt es folgende Variablen:
Report.InvoiceShipToAddress und hier dann entsprechend z.B. Report.InvoiceShipToAddress.Company oder Report.InvoiceShipToAddress.FirstName
Report.SalesOrderNumbers ist die Auftragsnummer, diese Variablen verwenden wir seit unserem Update auf die 1.6, das war eine der frühen 1.6 wenn ich mich richtig erinnere. Diese Variablen hatte ich damals im Testsystem vor dem Update des Hauptsystems gesehen und nach einem kurzen Test die Funktionalität bestätigt (wobei die Namensgebung in diesen beiden Fällen eigentlich schon deutlich ist).
 

Star Piercing

Sehr aktives Mitglied
1. Dezember 2012
1.365
373
Hätte ich ein Wunsch frei, dann würde ich mir Wünsche wieder auf eine 1.6 zurück (oder sogar die 1.5) zu downgraden.
Meine Herren wie viele Bugs ich jetzt schon gefunden habe... aktuell ist es so schlimm das ich gar keine Artikel mehr aufnehmen kann weil das Vererben/Drucken usw. rein überhaupt nicht funktioniert. Das ist echt bitter.
Und mir soll jetzt bitte niemand sagen das hier was getestet wurde.

Da muss echt ein Konzept hin! Bei so grössen updates muss eine Liste mit alltäglichen Arbeiten abgearbeitet werden und erst wenn alles funktioniert gibt man die Version frei.
 

MichaelH

Sehr aktives Mitglied
17. November 2008
14.147
1.766
Hätte ich ein Wunsch frei, dann würde ich mir Wünsche wieder auf eine 1.6 zurück (oder sogar die 1.5) zu downgraden.
Meine Herren wie viele Bugs ich jetzt schon gefunden habe... aktuell ist es so schlimm das ich gar keine Artikel mehr aufnehmen kann weil das Vererben/Drucken usw. rein überhaupt nicht funktioniert. Das ist echt bitter.
Und mir soll jetzt bitte niemand sagen das hier was getestet wurde.

Da muss echt ein Konzept hin! Bei so grössen updates muss eine Liste mit alltäglichen Arbeiten abgearbeitet werden und erst wenn alles funktioniert gibt man die Version frei.

Sehe ich auch so, wenn jeder Update eine " Stable" ist, aber es nicht wirklich stimmt ... siehe auch Diskussionen dazu.

JTL sollte nach Ablauf einer Zeit eine "vorige" Version die keine gravierende oder zumindest nur bekannte Bugs hat (die nicht schwerwiegend sind) als "stable" deklarieren.
Ansonsten ist man verloren im WirrWarr der Versionen.
 
  • Gefällt mir
  • Traurig
Reaktionen: SebiW und 301Moved

Manuel Pietzsch

JTL-Wawi
Mitarbeiter
2. Januar 2012
2.861
1.037
Hückelhoven
Hi,

...wäre sicherlich eine detailierte Checkliste von Nöten, um störungsfrei auf die 1.7 zu gehen. Das habt ihr ja bei dem Update auf die 1.0. auch hinbekommen.

https://guide.jtl-software.de/jtl-wawi/installation/checkliste-fuer-den-umstieg-auf-jtl-wawi-1-6/

hab grade gesehen, dass wir das schon gemacht haben. Wäre nett wenn du mal schaust und mir ggf. deine 50 Cent dazu gibst auf Anwendersicht. Können da gern noch optimieren.
Der Schritt von 1.6 auf 1.7 ist Kinderkram, wüsste nicht mal was man da groß prüfen soll, also speziell auf die 1.7 bezogen.

Gruß und Danke

Manuel
 

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
7.125
1.875
Berlin
Einen Kunden von mir hat es ganz schlimm erwischt, der wurde dazu überredet auf die 1.7er zu gehen.
Seit dem stürzt die Wawi auf allen Rechnern nur noch ab, der Support von JTL sagt ihm es liegt an seinen Rechnern die nicht geeignet sind..... :rolleyes: , wir sprechen von Rechnern mit einem I7 und 16GB RAM, die SQL Datenbank ist extern gehostet. Was also soll da jetzt nicht ausreichend sein?

Zusätzlich funktioniert so gut wie nichts mehr von seinen Arbeitsabläufen die er in der 1.5er wunderbar durchlaufen konnte.
Sein Betrieb steht nahezu still.

Ich kann also nur sagen, wer auf die 1.7er gehen möchte sollte sich das ganz genau überlegen, denn allein schon wenn ich solche Supportantworten bekomme und wenn ich in meinen Vorgängen jetzt so beschnitten werde, weil Funktionen einfach ersatzlos gestrichen werden dann gibt es keinen Grund sich das anzutun.

Fazit: Die 1.6er war für mich und die 1.7er ist für mich keine wirkliche Option, schon gar nicht wenn der Support hier so stümperhaft reagiert.
 

Manuel Pietzsch

JTL-Wawi
Mitarbeiter
2. Januar 2012
2.861
1.037
Hückelhoven
Einen Kunden von mir hat es ganz schlimm erwischt, der wurde dazu überredet auf die 1.7er zu gehen.
Seit dem stürzt die Wawi auf allen Rechnern nur noch ab, der Support von JTL sagt ihm es liegt an seinen Rechnern die nicht geeignet sind..... :rolleyes: , wir sprechen von Rechnern mit einem I7 und 16GB RAM, die SQL Datenbank ist extern gehostet. Was also soll da jetzt nicht ausreichend sein?

Zusätzlich funktioniert so gut wie nichts mehr von seinen Arbeitsabläufen die er in der 1.5er wunderbar durchlaufen konnte.
Sein Betrieb steht nahezu still.

Ich kann also nur sagen, wer auf die 1.7er gehen möchte sollte sich das ganz genau überlegen, denn allein schon wenn ich solche Supportantworten bekomme und wenn ich in meinen Vorgängen jetzt so beschnitten werde, weil Funktionen einfach ersatzlos gestrichen werden dann gibt es keinen Grund sich das anzutun.

Fazit: Die 1.6er war für mich und die 1.7er ist für mich keine wirkliche Option, schon gar nicht wenn der Support hier so stümperhaft reagiert.

Hi,

kannst du mir bitte die Ticketnummer nennen?

Gruß

Manuel
 

DITH-Shop

Sehr aktives Mitglied
8. Juli 2013
2.722
175
Ein Update sollte man auf jeden Fall erstmal auf einem Testsystem durchlaufen lassen.
Also auf irgendeinen ausgemusterten PC/Laptop einen SQL-Server installieren. Dort ein aktuelles Backup der Produktivdatenbank einspielen und dann ein Update machen.
Das kann ein uralter und langsamer PC sein, aber nur durch das echte Update kann man sehen, ob es durchläft. Jedes Skript, dass ein Update nur simuliert, aber doch nicht wirklich durchführt ist Käse.
Nebenbei übt man sich selbst darin, ein Backup wiederherzustellen und vor allem prüft man damit auch das erstellte Backup (was ein essentiell wichtiger Bestandteil jeder Backup-Strategie ist).

Das ist doch genau das was ich bereits schrieb.
Abgesehen davon das ich es mir nicht leisten kann für >3000 Euro ein Testsystem aufzusetzen (Windows Server + SQL DB + Hardware), habe ich auch nicht die Zeit (und Lust) immer wieder Updates, Backups, nochmal Update, nochmal Backup etc. durchzuführen um jeden einzelnen Fehler zu finden, zu beheben.. .
Ich kann mich wirklich anders beschäftigen.

Ein simples SQL Script welches prüft ob Tabellenänderungen durchgeführt werden können, oder ggf Felder in zugreifenden Views ein Update sperren, ist hingegen recht einfach umzusetzen.
 

css-umsetzung

Offizieller Servicepartner
SPBanner
6. Juli 2011
7.125
1.875
Berlin
Hi,

kannst du mir bitte die Ticketnummer nennen?

Gruß

Manuel
Ja lasse ich mir geben, ich habe dem Kunden auch gesagt das er dich am besten mal direkt anschreiben soll warum der Betrieb quasi stillsteht.
Der Kunde hat jetzt nach 4 Wochen der Qual alles, von der Firma die ihm das Update aufgeschwatzt hat, sehr aufwendig auf die 1.5er zurücksetzen lassen (hab ich nicht gemacht, hoffe aber nur das dabei nichts verloren gegangen ist)
 
  • Wow
Reaktionen: wawi-dl

DITH-Shop

Sehr aktives Mitglied
8. Juli 2013
2.722
175
  • Gefällt mir
Reaktionen: Harald Weingaertner

Ähnliche Themen