Frage: 🐌🐌🐌JTL-Wawi 1.9 - Wie schnell öffnet sich bei euch die Auftragsansicht?

[Powalowski]

Die einfache Antwort ist: Schnell genug. Wir brauchen den Prozess relativ selten, haben keine telefonische Auftragsannahme etc. Unsere Aufträge kommen rein, werden automatisiert abgefertigt und nur die relativ seltenen Problemfälle müssen händisch bearbeitet werden.
Dass die Öffnungszeit für Euch ein Problem ist liegt an Euren Prozessen. Und damit meine ich nicht dass Eure Prozesse schlecht sind sondern nur, dass eben keineswegs jeder so arbeitet wie ihr. Für uns stellt die Ladezeit von 1-2 Sekunden schlicht kein Problem dar. Für viele andere auch nicht.
Geht schon damit los dass die meisnte JTL User noch nichtmal auf 1.9 sind.

Wenn die Öffnungszeit eines Auftrags bis zu 10 Sekunden beanspruchen kann bei komplexen Aufträgen ist das ein Bug. Wenn der Dialog dabei noch einen absturzschaffenden Memoryleak erzeugt, dann erst recht.

Die Frage war: "wie schnell" es sollte quantifiziert werden. Ich kenne durchaus Leute, für die alles auf dem Computer "zu schnell" ist. Es ging um eine Quantifizierung.

Einfach gesagt läuft unter der Haube etwas verkehrt, wenn ein Formular mit 50 Feldern auf einen Computer mit 16 Kernen und 4Ghz mehr als 100ms zum Öffnen benötigt und anschließend seinen Speicher nicht freiräumt und Abstürze verursacht.

Ich gehe durchaus davon aus, dass alle Installationen betroffen sind, dieser Bug kritisch ist und dass der zuständige Entwickler beim Lesen dieses Beitrags vielleicht mal seine Fertigkeiten aufpoliert oder in seiner Freizeit an dem Problem weiter baut - ich jedenfalls könnte sowas nicht abliefern. Das Ziel: besser werden. Es wäre keine gute Haltung so einen Bug zu "dulden", nur weil es einige User nicht stört und der Aufschrei nicht groß genug ist . Wer ambitioniert ist, baut so einen Dialog mit Hingabe so ordentlich, dass der < 100ms benötigt.

 

[littled]

Die einfache Antwort ist: Schnell genug. Wir brauchen den Prozess relativ selten, haben keine telefonische Auftragsannahme etc. Unsere Aufträge kommen rein, werden automatisiert abgefertigt und nur die relativ seltenen Problemfälle müssen händisch bearbeitet werden.
Dass die Öffnungszeit für Euch ein Problem ist liegt an Euren Prozessen. Und damit meine ich nicht dass Eure Prozesse schlecht sind sondern nur, dass eben keineswegs jeder so arbeitet wie ihr. Für uns stellt die Ladezeit von 1-2 Sekunden schlicht kein Problem dar. Für viele andere auch nicht.
Geht schon damit los dass die meisnte JTL User noch nichtmal auf 1.9 sind.

Also sind es bei euch 1-2 Sekunden?
Die Rechtfertigung von dir gegenüber JTL finde ich aber schon schwach. D.h. es ist okay bestraft zu werden weil wir als Betrieb gewachsen sind? JTL hat nicht für Optimierung gesorgt und jetzt sind wir als Betrieb erstmal "gefangen". Mann kann jawohl davon ausgehen das normale Funktionen nicht erst 10 Sekunden "Aufwärmphase" brauchen damit sie benutzt werden können. Es ist egal ob ich einen Auftrag öffnen möchte oder eine Vorlage ändern möchte. Es dauert mindestens 5 Sekunden beim ersten öffnen, danach geht es dann meist in 2-3 Sekunden.

Das dieser Zustand für viele andere User okay ist wird wohl daran liegen das sie es nicht anders kennen und keine Ahnung haben wieviel Zeit verschwendet wird.

 

[SebiW]

@Powalowski Der zentrale Punkt ist: Du hast ein Problem damit dass der Prozess an dieser Stelle lahmt. Ich habe ein Problem damit, dass ich keinen Retourenprozess in der Beschaffung und keine aktuellen Amazon Listen habe. Und nun?

Niemand argumentiert dagegen dass da ein Bug vorliegt. Ich stelle schlicht fest: Dieser Bug ist für viele andere nicht so wichtig wie für Dich. Das ist schlecht für Dich. Verstehe ich. Ändert aber nichts an der Wahrheit meiner Aussage. Bitte lerne zwischen Botschaft und Boten zu unterscheiden.

Und ich wäre sehr dankbar dafür wenn Ihr hier davon absehen könntet andere Sichtweisen als mangelnde Kompetenz herabzuspielen. Genausogut könnte ich argumentieren: Bringt mal Eure Bestellprozesse auf die Reihe, dann müsst Ihr nicht ständig Aufträge anfassen. Wäre aber genauso unsinnig, es gibt halt verschiedene Businessmodelle.

 

[Powalowski]

@Powalowski Der zentrale Punkt ist: Du hast ein Problem damit dass der Prozess an dieser Stelle lahmt. Ich habe ein Problem damit, dass ich keinen Retourenprozess in der Beschaffung und keine aktuellen Amazon Listen habe. Und nun?

Niemand argumentiert dagegen dass da ein Bug vorliegt. Ich stelle schlicht fest: Dieser Bug ist für viele andere nicht so wichtig wie für Dich. Das ist schlecht für Dich. Verstehe ich. Ändert aber nichts an der Wahrheit meiner Aussage. Bitte lerne zwischen Botschaft und Boten zu unterscheiden.

Und ich wäre sehr dankbar dafür wenn Ihr hier davon absehen könntet andere Sichtweisen als mangelnde Kompetenz herabzuspielen. Genausogut könnte ich argumentieren: Bringt mal Eure Bestellprozesse auf die Reihe, dann müsst Ihr nicht ständig Aufträge anfassen. Wäre aber genauso unsinnig, es gibt halt verschiedene Businessmodelle.

Ich kann das sehr wohl unterscheiden. Bei den Lieferantenretouren fummeln wir auch seit Jahren mit Konventionen herum.
Verständlich, dass der Lieferantenprozess für Ärger sorgt. Versteht kein Mensch, warum man da Plan & Produce baut, anstatt diese Basics anzugreifen -die ja nun seit jahren im Issuetracker gewünscht werden-.

Der Bug muss weg.

Lieferantenretouren: Feature Request
Auftragseditor Memoryleak: Bug

 

[intrinsicforce]

[...] Genausogut könnte ich argumentieren: Bringt mal Eure Bestellprozesse auf die Reihe, dann müsst Ihr nicht ständig Aufträge anfassen. Wäre aber genauso unsinnig, es gibt halt verschiedene Businessmodelle.

Genauso ist es. Im B2B-Geschäft muss man häufig an die Aufträge ran. Geht erstmal mit Angebotserstellung los (Angebot öffnen ist bei uns ebenfalls ziemlich lahm). Dann kommt die eigentliche Bestellung, Auftrag wird erstellt. Dieser muss im Anschluss trotzdem nochmal geöffnet werden um die - sehr häufig zwingend notwendige - Bestellnummer des Kunden zu hinterlegen. Bei mir ist es so, und daher bin ich auch deutlich von der Performance-Einschränkung betroffen.

Andere wiederum haben nur B2C-Aufträge, die allesamt über Plattformen oder den Shop reinkommen. Da ist allenfalls mal eine Adresskorrektur notwendig, und die kann über den Packtisch erledigt werden. Da muss man dann eben kaum Aufträge bearbeiten, sodass ein solcher User gar nichts von dem Bug zu spüren bekommt.

Die Priorisierung von Issues seitens JTL stelle ich mir daher auch nicht einfach vor - und das ist ja bei weitem nicht das einzige Kriterium.

edit:

Lieferantenretouren: Feature Request
Auftragseditor Memoryleak: Bug

Das würde ich so allerdings auch unterschreiben.

 

[SebiW]

Nichts anderes wollte ich damit sagen @intrinsicforce
JTL priorisiert meiner Erfahrung nach nach Lautstärke des Aufschreis. Deshalb gab es bei den Amazon Abgleichen auch binnen Tagesfrist ne Notlösung für die eigentlich nicht mehr supportete 1.5. Da gabs schlicht nenn großen Bumm.
Insofern ist das hier beschrieben Problem bei JTL als wichtig genug für einen zeitnahen Fix aber nicht wichtig genug für einen Hotfix eingestuft worden.

Und schaue ich in den JTL Tracker hab ich bei offenen Bugs:

Amazon Lister - Amazon Flat Files weitere Marktplätze (EU) auf aktuellen Stand bringen - 29.11.2021 - 56 Votes - Status abgewiesen
Eingetragener Vater-GLD wird nicht gespeichert oder auf Kinder übertragen - 09.06.2022 - 32 Votes - Ohne Zielversion
Stornierte Aufträge werden als Bezahlt markiert - 18.07.2022 - 29 Votes - Ohne Zielversion
Lieferzeit ist falsch wenn eigener Lagerbestand = 0 und Lieferantenbestand dem eigenen hinzugefügt wurde - 15.01.2019 - 22 Votes - Ohne Zielversion
.
.
.
Memory Leaks beim Öffnen und Schließen von Aufträgen und Rechnungen - 19.04.2024 - 12 Votes - Zielversion 1.10.3.0

Hey, freut Euch, Euer Zeug wird wenigstens in absehbarer Zeit gefixed

 

[MichaelH]

Eben und daher ist die Aussage "Deshalb gab es bei den Amazon Abgleichen auch binnen Tagesfrist ne Notlösung für die eigentlich nicht mehr supportete 1.5." eher nicht zutreffend.
Es wird wohl noch große Kunden mit 1.5 geben die sich entsprechend stark gemacht haben.

Eine Anzahl von "kleinen Kunden" hat kein Gewicht.

Auch werden Bugs gerne als "wünschenswerte Features" bewertet denn als Bugs.

 

[Powalowski]

Stornierte Aufträge werden als Bezahlt markiert - 18.07.2022 - 29 Votes - Ohne Zielversion

Wahnsinn, da bringst mir aber etwas in die Aufmerksamkeit. Das ist uns schon ein paar Mal aufgefallen, dass man da dann genauer hinschauen muss mit der Zahlung. Wirkt ja nach totalem Handgriff, das zu beheben.

Ich frage mich ob da ein Top Entwickler einfach den Bugfixer besetzt, außerhalb aller Teams, vielleicht sogar mit wechselnder Position, der dann Bugs -und nur- Bugs weghaut.. Ich hör immer Product Owner, Product Owner.
Macht das Scrum weg.. 🙄 Oder zumindest darüber hinaus jemanden, der außerhalb der Konventionen eben Fehler fixt.

Freifahrtsschein: Nur Fehler fixen, ein Issue nach dem anderen wegknuspern bitte ☝🏻🍪

NACHTRAG: Wozu überhaupt eine Zielversion etc. einfach weghauen das Ding und dann ist das beiläufig gefixt.

 

[SebiW]

Eben und daher ist die Aussage "Deshalb gab es bei den Amazon Abgleichen auch binnen Tagesfrist ne Notlösung für die eigentlich nicht mehr supportete 1.5." eher nicht zutreffend.
Es wird wohl noch große Kunden mit 1.5 geben die sich entsprechend stark gemacht haben.

Eine Anzahl von "kleinen Kunden" hat kein Gewicht.

Auch werden Bugs gerne als "wünschenswerte Features" bewertet denn als Bugs.

Ob da jetzt sehr viele kleine oder wenige große Schreien dürfte ein ähnliches Gewicht haben. Schlicht weil die kleinen Kosten im Support verursachen und die großen für Einnahmeausfälle sorgen.
Oder anders: Ich würde mal vermuten JTL bewertet Bugs blank fiskalisch. Kann sein dass ein Bug sofort angegangen wird wenn ein Großkunde betroffen ist (die haben dann sicher auch die entsprechende Einzelbetreuung die in der Entwicklung Dampf machen kann), dürfte aber auch passieren wenn die Supporthotlines glühen damit Ruhe im Karton ist. Geld ist Geld.

 

[mh1]

Um mal wieder ein bisschen zurück zum ursprünglichen Kern des Threads zu kommen...

Wenn die Öffnungszeit eines Auftrags bis zu 10 Sekunden beanspruchen kann bei komplexen Aufträgen ist das ein Bug.

habt ihr die langen Reaktionszeiten nur bei den Aufträgen, oder generell bei allen Datenabrufen, also auch bei z.b. Artikel oder Kunden?

Wenn der Dialog dabei noch einen absturzschaffenden Memoryleak erzeugt, dann erst recht.

Der PC auf dem der Wawi Client läuft stürzt also nach mehrmaligen Auftrag öffnen ab?
Oder stürzt der Datenbankserver ab?

Was meinst du mit Memoryleak? Hat die Wawi ein Memoryleak? Wie hast du das festgestellt?

Aber zunächst noch die ernstgemeinte Frage:
besteht in diesem Thread noch das Interesse an einer Suche nach möglichen Ursachen für die langen Reaktionszeiten, oder geht es hier nur noch um die Entwicklungsprozesse bei JTL?

 

[Katsugo]

Deshalb gab es bei den Amazon Abgleichen auch binnen Tagesfrist ne Notlösung für die eigentlich nicht mehr supportete 1.5. Da gabs schlicht nenn großen Bumm.

Kleine Korrektur: Die Version 1.5 ist erst zum 31.07.24 abgekündigt, war zu dem Zeitpunkt und ist aktuell also offiziell noch supportet. Oder übersehe ich da was?
https://us9.campaign-archive.com/?u=a4f5880e72b9cfc7ab96d17b0&id=8877eb0f40#1.5

 

[ple]

Der PC auf dem der Wawi Client läuft stürzt also nach mehrmaligen Auftrag öffnen ab?

Ich glaube er meint das Verhalten wenn man zum Beispiel eine Auftrag 100 nacheinander öffnet und schließt, im taskmanager kann man sehen wie immer mehr RAM verbraucht wird bis es zum Absturz kommt, hatte ich auch bereits gemerkt. Der ram wird wohl nicht mehr freigegeben.

 

[Powalowski]

habt ihr die langen Reaktionszeiten nur bei den Aufträgen, oder generell bei allen Datenabrufen, also auch bei z.b. Artikel oder Kunden?

Hauptsächlich bei Aufträgen - Rechnungen (auch neuer Editor) gehen z.B. sehr schnell. Auch die Megaübersichten laufen schnell (im Verhältnis, schnell wäre, wenn z.B. 200-500 Einträge geholt würden und es pagen würde, aber so wie es ist mit ordentlich Hardware unter der Datenbank kann man durchaus damit leben!)
Ein Ähnliches Problem war irgendwo im Vorlageneditor bei Ausgabe 2.0 aber das ist ein Randthema.

Siehe: https://issues.jtl-software.de/issues/WAWI-77156

Der PC auf dem der Wawi Client läuft stürzt also nach mehrmaligen Auftrag öffnen ab?

Die Wawi, insbesondere die 32bit Variante hat ein Speicherlimit, das dann irgendwann erreicht ist.

Siehe: https://forum.jtl-software.de/threa...emoryleak-beim-oeffnen-von-auftraegen.222193/
Siehe: https://issues.jtl-software.de/issues/WAWI-76186

Ich freue mich, dass die Sachen in Arbeit sind, lassen wir mal JTL bauen 👍🏻

besteht in diesem Thread noch das Interesse an einer Suche nach möglichen Ursachen für die langen Reaktionszeiten, oder geht es hier nur noch um die Entwicklungsprozesse bei JTL?

Ich denke, ich habe das Problem detailiert geschildert und mit JTL und Community ausführlich besprochen. Ein bisschen Einblick in den Entwicklungsprozess und ein Rückenwind bei der Entscheidung der Entwicklungsweise wären natürlich wünschenswert.

Ich verstehe (auch aus unternehmerischer Sicht) zu gut, dass in der aktuellen Softwarewelt auf der Suche nach dem richtigen Erlösmodell auch schwache Ansätze, wie geschlossene Cloud und Saas auf den Tisch kommen und da ist es durchaus meine
Absicht für mehr Öffnung zu werben: Lieber offen (am liebsten Open Source) + Self Deployment + optionale Cloud und Support als Erlösmodell, anstatt Lock-In in eine geschlossene Struktur.

-> Verlässt den Rahmen dieses Themas also bleibt es ein Randkommentar, nicht zuletzt, weil solche Fehler bei einem offenen Modell sicherlich viel schneller behoben werden könnten

 

[Powalowski]

Ticket ist auf gelöst gesprungen, wir sind gespannt! 🔥
https://issues.jtl-software.de/issues/WAWI-77156

 

[ChrisTS]

Die neuste Ankündig per Mail sagt:

Wichtiger Hinweis: Abkündigung JTL-Wawi 1.5

Mit JTL-Wawi 1.9 profitieren Sie außerdem von einer deutlichen Verbesserung der Stabilität und Performance sowie von zahlreichen Features, die Ihren Arbeitsalltag erleichtern und Sie bei Ihrem erfolgreichen Handel unterstützen.

Würde ich gerne glauben aber nach 15 Jahren JTL Erfahrung 🤣

 

[P0ttwal]

Die neuste Ankündig per Mail sagt:

Würde ich gerne glauben aber nach 15 Jahren JTL Erfahrung 🤣

Ja, da musste ich auch schmunzeln

 

[sjk]

Gerade für solche Fälle sollte doch intern mit massiven Datenbanken getestet und Zeiten für gängige Arbeitsschritte erfasst werden. Wenn man sich da als Softwarehersteller dann auch Zeitschwellen setzt, wäre das viel eher aufgefallen, das da etwas zu langsam für den Endverbraucher ist. JTL zielt doch eigtl. nicht nur auf kleine Unternehmen sondern auch auch Großkunden ab.

Ich kann das auch nicht verstehen, dass es scheinbar keine verbindlichen Anforderungen an die Geschwindigkeit der Dialoge gibt. Mal als konkreten Datenpunkt, weil die Marktbegleiter mit den vielen O's sogar konkret damit werben:

Erlebe wahre Geschwindigkeit, reduzierte Dateneinträge, intelligente KI und eine schnelle Benutzeroberfläche. Alle Vorgänge werden innerhalb von 90 Millisekunden erledigt – schneller als du schauen kannst.

edit: Geht mal auf deren Youtube-Kanal und klickt euch durch ein paar Tutorial Videos. Da steigen euch die Tränen in die Augen, wie flüssig das alles ist. Und man kann natürlich auch komplett mit der Tastatur durchfliegen.

 

[bilder_lf]

@Threderöffner? Gefühlt ca. 1 Minute

 

[wawi-dl]

edit: Geht mal auf deren Youtube-Kanal und klickt euch durch ein paar Tutorial Videos. Da steigen euch die Tränen in die Augen, wie flüssig das alles ist. Und man kann natürlich auch komplett mit der Tastatur durchfliegen.

Naja das kan JTL auch bald in der Cloud, dann sogar unter 90ms

 

[neustanlo]

Hi,

wir haben auch das Problem, dass die Artikelverwaltung und Auftragverwaltung sehr träge ist.

Unser lokaler Server schaut wie folgt aus:

HPE ProLiant ML350 GEN10
Windows Server 2022 Datacenter
Intel Xeon(R) Silver 4210 CPU @ 2,20 Ghz - 2.19 GHz (2 Prozessoren) insgesamt 20 Kerne
320 GB RAM DDR4
1.92 TB 6G SATA SSD


Der Client wie folgt:

Intel i9-10900K
64 GB RAM DDR4
Samsung PRO 990 4 TB
Windows PRO 11

An der Hardware kann es nicht liegen, dass die Zugriffszeiten sehr sehr langsam sind und teilweise stark hängen.

Ich bin ratlos, was ich noch machen (kaufen) müsste das ich eine Echtzeit bearbeitung haben kann.

Client ist per LAN verbunden.

Hat sonst noch jemand solche Probleme?

LG.