Neu REST-API nur noch für Premium Kunden - oder wie verhindere ich Nutzung moderner Schnittstellen...

[ple]

Geht mal davon aus, das auch nicht alles in Stein gemeißelt ist, dafür ist die Softwarewelt zu dynamisch.
JTL ist gerade in einem Transformationsprozess.

Mh, also gibt es noch eventuell Änderungen der Kosten oder wie?
Die gefühlvollen Kommentare hier sind garantiert nicht gegen euch JTL Mitarbeiter gerichtet, auch bei euch fällt die Scheiße von oben nach unten. @Nina L. tut einem schon sehr leid.
Ich hoffe, dass die meisten Kommentare und Bedenken an die GF weitergeleitet wird oder die selber hier mitlesen.

Was die Thematik der API sowie Custom Workflows angeht, dass kann ich nicht nachvollziehen. Vor 10 Jahren habe ich mich für JTL entschieden, ein Grund mit war das Forum hier.
Man hat sich hier sehr gut aufgehoben gefüllt und sehr viel gelernt. Man hat immer einen freundlichen User / SP'ler / JTL Mitarbeiter gefunden, der einem weiterhelfen konnte, auch mal ohne direkt einen Stundenzettel zu schreiben.
Sowas gibt es aktuell für kein anderes ERP System, zumindest habe ich noch keins gefunden.
Und mal ehrlich, wie viele sind klein angefangen mit der Wawi und gewachsen und brachten dann das Geld zu JTL? Wie viele setzen JTL Wawi ein, weil es einem empfohlen wurde?
Wir sind kostenlos angefangen, haben festgestellt, es funktioniert im groben, dazu brauchten wir ca. 5 Monate. Sind dann mit Ebay gestartet, dann JTL Shop, Eazyshipping und JTL hat ab den Zeitpunkt wahrscheinlich Geld an uns verdient.
Dazu kommt noch, dass wir etliche Bugs gemeldet haben die Jahre über, die auch JTL geholfen haben.
Dann einige Custom Workflows gekauft, z.b. Merkmale setzen, das erleichtert uns die Arbeit so dermaßen, aber wir können keine 200€ mehr ausgeben für die pro, egal was da alles noch zusätzlich drin ist. Große Unternehmen können vielleicht mal 25.000€ für ne Wechsel hinlegen und da ist es wahrscheinlich auch egal ob es klappt oder nicht.
Und bzgl Custom Workflows, mal ehrlich. Ob ich die SP mittels JTL auslöse oder die SP aus einem PS Script, dass ist doch völlig egal, es ist und bleibt ein SQL Query. Denke das wisst ihr auch, daher frage ich mich, wie wollt ihr das unterbinden für die Advanced? Doch alles in die Cloud?

Ich für meinen Teil glaube, dass JTL nicht nur von den Paketen leben kann, sondern eher von der Community und ganz besonders von den SP'lern, denn die haben doch Neukunden gebracht und davon sind einige bestimmt groß geworden, woran JTL Geld verdient. Warum die nicht mit ins Boot holen bei wichtigen Entscheidungen? Die kennen doch die Kunden und was eingesetzt wird.

Sicherlich habe ich zwischendurch mal über den Tellerrand geschaut, was es noch so gibt, aber mal ehrlich, mein Kollege ist eine 1 Mann Bude, ich mache nur nebebei JTL und automatisiere, damit mein Kollege es leichter hat.
Wenn ich dann Preise von weit über 400€ monatlich + 5000€ Migration lese, dann kann ich schon ablehnen. Ich kaufe doch nicht die Katze im Sack und zweitens will ich wissen was da passiert und das liebe ich an JTL.
Finanziell für 1 mal machbar, danach nicht mehr und wir sind wieder bei Excel und nichts automatisiert.
JTL habe ich mir angeeignet, habe dafür PS Scripte geschrieben, automatisiert, Datenbankstruktur kennengelernt. API wollte ich jetzt mit anfangen, ist aber wohl auf Eis gelegt gerade.

Aktuell hampel ich gerade mit Odoo rum, naja, die ersten Probleme kommen schon mit den Kategorien, aber ich muss anscheinend einen Plan b haben für die Zukunft.

 

[ple]

Dazu kann ich nichts konkretes mehr beitragen. Ich hoffe aber auch das die aktuellen Lösungen nochmal überdacht werden.
WMS ist für kleine Kunden echt teuer geworden und für große viel billiger.

Wenn du irgendwo ne Strichliste führen musst, wie viele Leute was bemängeln, dann mach da ruhig ein paar Striche mehr hin

 

[recent.digital]

Es ist davon auszugehen, dass die Geschäftsleitung das Feedback im Forum liest. Also schön sachlich weiter Feedback geben

(Wir als Servicepartner verweisen gerne und oft auf die entsprechenden Forenbeiträge)

 

[SebiW]

Jo, deshalb schreibe ich auch Ihr und nicht Du. Dass das nicht auf den Mist von _fwenzl gewachsen ist leite ich schon daran ab, dass Du im Forum mit uns in die Kommunikation gehst
Vorne am Namen steht aber nunmal JTL. Und uns als Kunden bleibt an dieser Stelle auch kaum was anderes übrig als laut sein. Wir sind nicht Teil der Entwicklungs- und Entscheidungsprozesse, insofern können wir nur die Ergebnisse kommentieren.

 

[sjk]

Ich kann es schon nachvollziehen, wenn man selbst kostenpflichtige Services anbietet....Da geht dann die Angst um. daß jemand mit API dann als 3rd Person diesen Dienst GÜNSTIGER oder besser anbieten kann und damit den eigenen Umsatz schmälert (z.B. Track & Trace, da binde ich z.B. 17track.net an für schmalen Taler, gestaffelt nach Anzahl der Sendungen pro Monat....mit allen Carriern, nicht nur denen die TT unterstützt). Aber mancher Kunde nimmt den Dienst trotzdem bei JTL, weil viele Köche und Brei und Supportpingpong, wenns nicht klappt.....

Selbst wenn es ein Dritter günstiger anbietet, eine Lösung aus einer Hand ist immer auch etwas wert, wie du es ja auch sagst. Im besten Fall spielt man als Hersteller da auch seine Position voll aus, Zugriff auf das gesamte Ökosystem zu haben. Im Fall von Track & Trace wäre das zum Beispiel, das Tracking auch in den JTL Shop zu pushen und damit eine top Statusseite für die Kunden bereit zu stellen. Die Daten sind sowieso in der Wawi. Man hätte damit ein Argument mehr für T&T UND für den JTL Shop geschaffen und als Kunde habe ich einen echten Mehrwert, für den ich dann auch eher bereit bin bei JTL evtl etwas mehr, als bei einem Dritten zu bezahlen. Dieses Prinzip lässt sich beliebig auf alle anderen Bereiche übertragen.

Augenscheinlich war bei JTL in den letzten Jahren eher Land unter mit den ganzen Umstellungen usw. Da wird für vieles einfach die Kapazität, der Fokus oder was auch immer gefehlt haben. Ich hoffe wirklich für die Entwickler, dass jetzt einmal alles konsolidiert werden kann, dass die Entwicklung professioneller werden kann und dass die Entwickler danach noch eine gewichtige Stimme im neuen Konstrukt haben werden. Wenn man nämlich mal jemanden von der Entwicklung erwischt, dann sind das bei JTL in der Regel motivierte, offene Menschen mit Ideen, oder nicht?

Vor 10 Jahren habe ich mich für JTL entschieden, ein Grund mit war das Forum hier.

Wir sind vor knapp 5 Jahren zu JTL gekommen, über eine Empfehlung. Die Entscheidung fiel bei uns auch durch das Forum und durch die Flexibilität der verschiedenen Module, und nicht zuletzt durch die Möglichkeiten eigenes zu entwickeln, die wir durch on-prem erhalten.
Seitdem haben wir durch unsere Empfehlungen bei 4-5 Händlerkollegen zu einem Wechsel zu JTL beigetragen, und bei der Umstellung mit Rat und Tat geholfen.
Bei all diesen Händlerkollegen war der ausschlaggebende Grund zu wechseln, dass sie in ihren Altsystemen entweder in unflexiblen Paketen eingeengt waren (bei vielen anderen sind die Preissprünge zwischen Paketen ja deutlich extremer), oder dass die Altsysteme von vornherein nicht genug anpassbar waren (Stichwort SaaS), bzw. nur in Enterprise Paketen und mit horrend teuren Beratern/Entwicklern.
Das ist in unseren Augen DER USP von JTL, dass man sich kleine Dinge zusammenbasteln kann und damit die Wawi zu seiner eigenen Wawi macht. Das ist mitunter auch ein großer retention Faktor. Diese ganzen Anpassungen und kleinen Tools, die wir andocken, das würde es uns unglaublich aufwändig machen zu wechseln.
Nur mal als Beispiel.

WMS ist für kleine Kunden echt teuer geworden und für große viel billiger.

Wir sind in unseren 5 Jahren mit JTL aus einer 1,5 Mann Bude heraus ordentlich gewachsen und hatten vor, in den nächsten 1-2 Jahren WMS einzuführen. Unser Lager ist relativ überschaubar, wir haben unter 500 SKUs. Ein WMS ist für uns overkill, aber wir mögen schöne Prozesse und weil wir jetzt neu auch Plan&Produce haben wäre es ein nice-to-have. Da wir "anspruchsvolle Lagerbewegungen" aka MHD/Charge haben (sorry, MHD/Chargen/Seriennummern verfolgen zu können ist ein absolutes Basisfeature jeder Lagerverwaltung und sowieso rechtlich erforderlich. Das ist kein ausgeklügelter, anspruchsvoller Versand-/Umlagerungs-/Einlagerungsprozess o.ä. sondern einfach ein paar zusätzliche Felder, das habe ich noch nie verstanden, warum das so viel extra kosten soll) landen wir mit zwei Packtischen jetzt bei 500€ allein für WMS. Klar ist das WMS ein mächtiges Modul und seinen Preis absolut wert, vor allem wenn ich das mit den 125€ für die Workbench vergleiche, die sich immer noch absolut nach einem umlackierten Packtisch in der Beta anfühlt. Aber die Pläne sind für uns jetzt erstmal auf unbestimmte Zeit vom Tisch.
Nur mal als Beispiel, die Zweite.

 

[T4DT.GmbH]

Da es hier schon mal erwähnt wurde: C#-Entwickler, die eigene Projekte erstellen wollen, aber sich mit der JTL Datenbank nicht auseinander setzen wollen ( mit jedem Update von vorn), können lizensiert auf unser SDK zugreifen (per Nuget-Feed):
Die Doku findet ihr hier: https://jtlmodel.doc.t4dt.com/ (natürlich nur für Entwickler geeignet). Es handelt sich um eine Übersetzungsengine, welche die JTL-Datenbank in allen von JTL unterstützen Versionen kennt und euch fertige Endpoint-Methoden bereitstellt, um Aufträge, Artikel, Umlagerungen etc. schreiben und lesen zu können.
Die Doku-Seite aktualisiert sich automatisch selbst. Die Use cases sind KI-generiert und machen daher nicht immer zu 100% Sinn, sondern sollen eine Orientierung zur Implementierung geben.
In den Endpoints stehen immer alle Methoden.

Das Preismodell: Der erste benannte Softwareentwickler (Microsoft-Konto) kostet 1.300€ / Jahr, jeder weitere derselben Domäne 400€ / Jahr.

 

[Powalowski]

Da es hier schon mal erwähnt wurde: C#-Entwickler, die eigene Projekte erstellen wollen, aber sich mit der JTL Datenbank nicht auseinander setzen wollen ( mit jedem Update von vorn), können lizensiert auf unser SDK zugreifen (per Nuget-Feed):
Die Doku findet ihr hier: https://jtlmodel.doc.t4dt.com/ (natürlich nur für Entwickler geeignet). Es handelt sich um eine Übersetzungsengine, welche die JTL-Datenbank in allen von JTL unterstützen Versionen kennt und euch fertige Endpoint-Methoden bereitstellt, um Aufträge, Artikel, Umlagerungen etc. schreiben und lesen zu können.
Die Doku-Seite aktualisiert sich automatisch selbst. Die Use cases sind KI-generiert und machen daher nicht immer zu 100% Sinn, sondern sollen eine Orientierung zur Implementierung geben.
In den Endpoints stehen immer alle Methoden.

Das Preismodell: Der erste benannte Softwareentwickler (Microsoft-Konto) kostet 1.300€ / Jahr, jeder weitere derselben Domäne 400€ / Jahr.

@T4DT.GmbH
Und wie lange wird diese SDK noch funktionieren? Oder ist da auch schon EOL im Anmarsch?

An sich wäre eine zuverlässige Rest-API schon das Schönste. Die Preisabschrekung ist aus meiner sicht aber enorm. Selbst bei 300€ pro Monat Mittelpaket von JTL muss man dann monatlich noch 100€ für die API zahlen. Da ist man ja schon fast schon hingerissen mit C# loszulegen 😂
Die JTLwawiExtern.dll scheint ja auch auf dem Abstellgleis.

 

[FOC Solutions]

@T4DT.GmbH
Und wie lange wird diese SDK noch funktionieren? Oder ist da auch schon EOL im Anmarsch?

An sich wäre eine zuverlässige Rest-API schon das Schönste. Die Preisabschrekung ist aus meiner sicht aber enorm. Selbst bei 300€ pro Monat Mittelpaket von JTL muss man dann monatlich noch 100€ für die API zahlen. Da ist man ja schon fast schon hingerissen mit C# loszulegen 😂
Die JTLwawiExtern.dll scheint ja auch auf dem Abstellgleis.

Die JTLwawiExtern.dll ist praktisch tot und wird nicht mehr weiterentwickelt. Die Fehler wurden immer mehr und ständig mussten wir drumherum programmieren. JTL verweist nur auf die Rest.api, nur kann diese für unsere Cases nichts genug. Dann haben wir beschlossen alles direkt in die DB zu schreiben, natürlich mit Versionskontrolle.

 

[Powalowski]

@FOC Solutions, @T4DT.GmbH
Interesssant, dass zwei Servicepartner hintereinander gar nicht die offizielle JTL Integration nutzen. Wie gut, dass diese 200€ pro Monat kosten soll.

 

[T4DT.GmbH]

@T4DT.GmbH
Und wie lange wird diese SDK noch funktionieren? Oder ist da auch schon EOL im Anmarsch?

Wir benutzen unser SDK auch selbst für unsere Software. Da laufen viele 100 Mio drüber. Das wird noch viele Jahre genutzt werden

 

[Powalowski]

Wir benutzen das SDK selbst für unsere Software. Da laufen viele 100 Mio drüber. Das wird noch viele Jahre genutzt werden

Diese Aussage sollte in Stein gemeißelt, groß und sichtbar ganz oben angepinnt werden. Die Entwicklung der letzten Wochen könnte nämlich anderes vermuten lassen 😬Es gibt wohl Zweifel, ob eine so integrierte SDK noch funktioniert, nachdem die SaaS transformational Leader ihre Mission erfüllt haben.
*wink* siehe Beitragstitel *wink*

 

[T4DT.GmbH]

Diese Aussage sollte in Stein gemeißelt, groß und sichtbar ganz oben angepinnt werden. Die Entwicklung der letzten Wochen könnte nämlich anderes vermuten lassen

Du hast mich jetzt ein bisschen verwirrt. Was genau meinst du mit "Die Entwicklung der letzten Wochen". Mir ist nicht bewusst, dass du unser SDK einsetzen würdest

 

[Powalowski]

Du hast mich jetzt ein bisschen verwirrt. Was genau meinst du mit "Die Entwicklung der letzten Wochen". Mir ist nicht bewusst, dass du unser SDK einsetzen würdest

Ich meinte das im Bezug auf eine mögliche Cloud-Zukunft und die Entwicklungen seitens JTL. Eine SDK, die direkt auf die Datenbank zugreift, geht nur dort, wo die Datenbank tatsächlich liegt. Eine mögliche Negativauslegung einer SaaS Transformation der Wawi könnte z.B. Cloud-Only sein und damit wäre die Zukunft des direkten Datenbankzugrifss ungewiss. Und da in den letzten Wochen über Nacht das Preismodell komplett umgeworfen wurde, könnte man am Bestand der Softwarestrategie als solches zweifeln. Ich hoffe nicht, deshalb würde ich mich freuen, wenn die SDK noch viele Jahre geht 👍🏻👍🏻

 

[elevennerds.de]

Eigentümer der Daten ist und bleibt die jeweilige Firma. Ich denke, für Viele wird das der einzige Grund für JTL gewesen sein, die Hoheit über die eigenen Daten zu haben. Ich würde jetzt gern schreiben, dass ich JTL das nicht zutrauen würde, zu versuchen, da mit der großen Schere ranzugehen. Mittlerweile traue ich JTL aber sehr viel zu... daher auf alles vorbereitet sein.

 

[FOC Solutions]

Eigentümer der Daten ist und bleibt die jeweilige Firma. Ich denke, für Viele wird das der einzige Grund für JTL gewesen sein, die Hoheit über die eigenen Daten zu haben. Ich würde jetzt gern schreiben, dass ich JTL das nicht zutrauen würde, zu versuchen, da mit der großen Schere ranzugehen. Mittlerweile traue ich JTL aber sehr viel zu... daher auf alles vorbereitet sein.

Wir haben viele große und sehr große Kunden die JTL benutzen, teilweise mehr als 100mio Jahresumsatz. Für diese ist es völlig ausgeschlossen die Datenhoheit abzugeben. Da JTL ja immer größere Kunden anzieht, die oft auch richtig viel Geld an JTL zahlen (nach alter Struktur teilweise 5k im Monat), wird JTL es nicht wagen diese Kunden zu verprellen.

Im Umkehrschluss wird sich die Softwarequalität von JTL verbessern müssen, da diese großen Kunden JTL dann auch schnell die Rechtsabteilung auf den Hals hetzen, wenn kritische Fehler nicht zügig gefixt werden. JTL will den Enterprise Ansatz, dann aber auch komplett!

 

[T4DT.GmbH]

Eigentümer der Daten ist und bleibt die jeweilige Firma. Ich denke, für Viele wird das der einzige Grund für JTL gewesen sein, die Hoheit über die eigenen Daten zu haben. Ich würde jetzt gern schreiben, dass ich JTL das nicht zutrauen würde, zu versuchen, da mit der großen Schere ranzugehen. Mittlerweile traue ich JTL aber sehr viel zu... daher auf alles vorbereitet sein.

Daher werden wir unser SDK auch weiter entwickeln. Die Datenhoheit bleibt komplett bei der lokalen Anwendung.

 

[T4DT.GmbH]

Ich meinte das im Bezug auf eine mögliche Cloud-Zukunft und die Entwicklungen seitens JTL. Eine SDK, die direkt auf die Datenbank zugreift, geht nur dort, wo die Datenbank tatsächlich liegt.

Ich glaube es wird, wenn es soweit ist, eine ähnliche Transition geben, wie beim Haufe Verlag:
- Lexware als on premise wurde ersetzt durch lexoffice und Haufe x360, wird aber als on prem Lösung nach wie vor supportet, aber eben nicht mehr ergänzt).

Wir betreuen auch Konzern-Kunden, für die eine lokale Datenspeicherung unabdingbar ist. Daher wird dieser Dualismus ziemlich sicher noch eine Weile erhalten bleiben. Eine Cloud-native Anwendung wird sicherlich nicht auf Basis der heutigen Wawi entwickelt werden, sondern nur mit den Erfahrungen dessen.

 

[Powalowski]

Schön, solche Aussagen

wird JTL es nicht wagen diese Kunden zu verprellen.

Die Datenhoheit bleibt komplett bei der lokalen Anwendung.

von SP Schwergewichten zu hören💪🏻. Hat jemand von euch schon mit HG gesprochen oder entsprechende Zusagen erhalten, dass das auch so bleibt?

Eine Cloud-native Anwendung wird sicherlich nicht auf Basis der heutigen Wawi entwickelt werden

Das sollte für die On-Prem Variante eigentlich auch gelten. Eine Cloud Wawi sollte am besten ein moderner Container (idealerweise komplett offen) sein, der für JTL ebneso leicht in der Cloud zu skalieren und zu maintainen ist, wie für die Kunden auf eigener Hardware. Das aktuelle RDP-Konzept ist ja wirklich nicht leicht als Cloud zu skalieren .. Im Anbetracht einer möglichen Negativentwicklung jedoch plötzlich durchaus akzeptabel 😂