Neu Was hält dich noch auf der 1.5?

[DITH-Shop]

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]

Es gibt ja eine Seite von JTL wo genau beschrieben wird welche DB Felder weech sind bzw. anders heißen. Reicht das nicht?

 

[mh1]

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]

Es gibt ja eine Seite von JTL wo genau beschrieben wird welche DB Felder weech sind bzw. anders heißen. Reicht das nicht?

Nein weil ich als Anwender trotzdem viel Zeit investieren muss um die individuellen Lösungen anzupassen und wir hier von einigen Stunden sprechen.

 

[301Moved]

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.

 

[gnarx]

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]

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]

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]

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.

 

[Manuel Pietzsch]

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

 

[Pinkman]

Der Schritt von 1.6 auf 1.7 ist Kinderkram

ja das ist es, ABER es scheint das die einige Bugs mit sich bringt, die in der 1.6. funktionieren.
Ich bin immer einer der ersten gewesen, aber diesmal habe ich mich zurückgehalten

 

[Manuel Pietzsch]

ja das ist es, ABER es scheint das die einige Bugs mit sich bringt, die in der 1.6. funktionieren.
Ich bin immer einer der ersten gewesen, aber diesmal habe ich mich zurückgehalten

Aber was heißt das für eine Checkliste?

 

[MichaelH]

Aber was heißt das für eine Checkliste?

Pinkman ist schon auf JTL WAWI 1.6.41.2 - ist also ein anderes Thema.

 

[css-umsetzung]

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..... , 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]

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..... , 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]

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.

 

[DITH-Shop]

Es gibt ja eine Seite von JTL wo genau beschrieben wird welche DB Felder weech sind bzw. anders heißen. Reicht das nicht?

Eine Doku wo welches Feld entfernt, hinzugefügt, oder auf ein anderes Datenformat geändert wird, kann ich nicht finden.
Bitte nenne mir den Link.

 

[css-umsetzung]

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)

 

[gnarx]

Eine Doku wo welches Feld entfernt, hinzugefügt, oder auf ein anderes Datenformat geändert wird, kann ich nicht finden.
Bitte nenne mir den Link.

Oben über die Kategorien findest du alles: https://wawi-db.jtl-software.de

Unter Compare kannst du vergleichen die Versionen-

 

[DITH-Shop]

Oben über die Kategorien findest du alles: https://wawi-db.jtl-software.de

Unter Compare kannst du vergleichen die Versionen-

Super - vielen Dank.

und schon bin ich raus aus allem was über 1.5.55 hinausgeht.

Für mich dringend notwendige Tabellen sind rausgeflogen

dbo.trechnung​

dbo.tReserviert​

dbo.tVersandInfo​