Neu Neue Preiserhöhung JTL April +~20% für Monatstarife, eingeschränkte "Funktionalitäten"

[Groundhog]

Genau diese Frage finde ich aktuell auch sehr interessant. Ich glaube, eine echte Alternative zu JTL muss nicht nur einzelne Funktionen ersetzen, sondern vor allem einen sicheren Übergang ermöglichen.

Genau deshalb habe ich den JTL-Wawi → Odoo 19 Connector entwickelt. JTL kann während der Migration weiterlaufen, während Odoo parallel aufgebaut, Daten übernommen und die Prozesse getestet werden. Erst wenn alles geprüft ist, erfolgt der eigentliche Wechsel.

Mir war dabei wichtig, keine „Big-Bang“-Migration vorauszusetzen und auch keine halbfertige Lösung zu liefern.

Gerade deshalb würde mich interessieren, welche Bereiche für dich bei einer echten JTL-Alternative unverzichtbar wären.

Ich hab mir Odoo angesehen und auch getestet. Es gibt hier sehr sinnige Funktionen und auch die Modulbauweise ist durchaus gut gelöst. Einige meiner Lieferanten arbeiten mit Odoo. Für mich ist Odoo aber aufgrund der eingeschränkten Shopfunktionen einfach keine Option. Kassenanbindung läuft auch nicht so einfach in Österreich. Plugins bräuchte ich für Anbindungen an die Post beispielsweise auch wieder. Anpassungen, neuer Shop - all das sind Kosten, wiederholt.

Würde ich nochmal (mit dem Wissen von heute) von vorne starten, dann ja. Auch wenn alle Entwickler und Agenturen mich gewarnt haben, dass Major Updates bei Odoo schwierig sind, Migration teilweise dann nur eingeschränkt möglich ist. All das ist, Stand jetzt, einfach für mich keine Option.

Seit einiger Zeit überarbeite ich alle meine Abläufe und habe damit einiges an Software durch containerisierte Open Source Alternativen ersetzt. Ich sehe das für eine derart komplexe Warenwirtschaft zwar nicht so schnell kommen - aber wenn ich mir die Entwicklungen der letzten Monate ansehe, dann werden wir wohl Probleme dieser Art bald vollständig über ein LLM lösen können.

Für meinen Teil habe ich mir die Unzulänglichkeiten einfach von Claude lösen lassen und mir ein Dashboard gebaut über welches ich die Einsichten, Auswertungen und Funktionen so habe, wie ich sie brauche und haben will. Für mich löse ich es einfach Selbst - wie eben schon so oft. Durch den Fortschritt, den ja die meisten Dienstleister wie Zahlungsanbieter, Versandienstleister udgl. (Api's, MCP's, etc...) machen, glaube ich, dass wir uns in einem absehbaren Zeithorizont keine fertige Softwarelösung mehr aufbürden lassen müssen um ein Problem zu lösen.

 

[MichaelH]

Ich kenne Odoo oder andere Software als JTL nicht bzw. nicht im Detail.

Doch bei modularer Bausweise muss man sich doch immer fragen:
Warum sollte man/ich ein Odoo Major-Update überhaupt benötigen ?

 

[recent.digital]

Beispielsweise weil irgendeine Komponente ein Update erfordert z. B. weil ein Versanddienstleister eine Schnittstelle erneuert.

Lizenzen geben einem Lizenzgeber alle möglichen Freiheiten.

 

[MichaelH]

Beispielsweise weil irgendeine Komponente ein Update erfordert z. B. weil ein Versanddienstleister eine Schnittstelle erneuert.

Lizenzen geben einem Lizenzgeber alle möglichen Freiheiten.

Das wäre entgegen einem Modul-Konzept, ein Major-Update wegen einer bestehenden Schnittstelle ?!?
So sollte es eben genau nicht sein.

Die Anpassung mag was kosten, aber ich muss nicht die komplette Software updaten wegen so einem PiPiFatz ... denn das kennt man ja schon. 😉

Die KI sagt dazu:

Odoo hat eine Open-Source-Variante (Odoo Community Edition), bei der Sie den Quellcode vollständig einsehen und Schnittstellen (APIs/Module) selbst anpassen können, wenn sich diese ändern.
Allerdings hängt der genaue Spielraum von der gewählten Version und dem Hosting-Modell ab. Hier ist die Übersicht, wie sich das verhält:

Die beiden Odoo-Versionen im Vergleich

• • Odoo Community: Diese Version ist 100 % Open-Source (unter der LGPLv3-Lizenz). Sie können bestehende Schnittstellenmodule komplett anpassen, eigene Konnektoren programmieren oder den Code verändern, um ihn an neue Anforderungen von Drittsystemen anzupassen.
  • Odoo Enterprise: Dies ist die lizenzpflichtige proprietäre Version. Sie enthält zusätzliche Funktionen und erweiterte Schnittstellen. Der Kern ist zwar nicht Open-Source, aber Odoo erlaubt es Entwicklern über das sogenannte Framework-Overriding (Erstellen von eigenen Custom-Modulen), bestehende Schnittstellen zu erweitern oder abzuändern, ohne den geschützten Kerncode direkt zu bearbeiten.

 

[SebiW]

Wir sind auch in der Planung einer Umstellung auf Odoo. Bei den Shops haben wir uns bereits in Richtung Shopware verabschiedet.
Das Problem, das ich bei JTL sehe ist zweigeteilt: Erstens ist die Preisentwicklung komplett wahnsinnig. Für das, was wir mittlerweile auf unseren zwei Mandanten bei JTL bezahlen kann ich fast schon Richtung SAP schauen...
Das viel größere Problem ist, das JTL immer stärker Richtung SaaS und Cloud wandert. Für uns eine völlig inakzeptable Entwicklung. Insbesondere weil die Qualität der Cloudlösungen teils hanebüchen ist. Shipping 2.0 ist ein Trauerspiel. Der Shopwareconnector wird alle paar Monate mal wieder auf Stand gebracht, üblicherweise hat Shopware da schon 4-5 Versionsupdate raus.

Und eine Eigenlösung via LLM sehe ich nicht. Nicht weil ich das nicht für möglich halte. Sondern weil hier einfach zu viele externe Gefahrenfaktoren reinspielen. In den letzten Jahren hatten wir OSS, Omnibus, aktuell Entsorgung etc. Hier eine rechtskonforme Lösung zu basteln würde voraussetzen, das man sich komplett in die entsprechenden Themenfelder einarbeitet, insbesondere weil der Informationsstand regelmässig unkomplett und fließend ist. Am Ende des Tages haftet die Firma für falsche Rechnungsstellung, Steuerabgabe etc.

Aber ein selbst geschriebener Connector für bspw das Shopsystem oder Marktplätze? Sicher denkbar. Sorge bereitet mir hier eher die Frage an welcher Stelle die LLMs anfangen werden die laufenden Kosten auf den User umzulegen. Ich möchte ungerne den Kostenfaktor JTL gegen einen ähnlich großen Kostenfaktor LLM plus Eigenarbeit tauschen.

 

[sebjo82]

Wir sind auch in der Planung einer Umstellung auf Odoo. Bei den Shops haben wir uns bereits in Richtung Shopware verabschiedet.
Das Problem, das ich bei JTL sehe ist zweigeteilt: Erstens ist die Preisentwicklung komplett wahnsinnig. Für das, was wir mittlerweile auf unseren zwei Mandanten bei JTL bezahlen kann ich fast schon Richtung SAP schauen...
Das viel größere Problem ist, das JTL immer stärker Richtung SaaS und Cloud wandert. Für uns eine völlig inakzeptable Entwicklung. Insbesondere weil die Qualität der Cloudlösungen teils hanebüchen ist. Shipping 2.0 ist ein Trauerspiel. Der Shopwareconnector wird alle paar Monate mal wieder auf Stand gebracht, üblicherweise hat Shopware da schon 4-5 Versionsupdate raus.

Und eine Eigenlösung via LLM sehe ich nicht. Nicht weil ich das nicht für möglich halte. Sondern weil hier einfach zu viele externe Gefahrenfaktoren reinspielen. In den letzten Jahren hatten wir OSS, Omnibus, aktuell Entsorgung etc. Hier eine rechtskonforme Lösung zu basteln würde voraussetzen, das man sich komplett in die entsprechenden Themenfelder einarbeitet, insbesondere weil der Informationsstand regelmässig unkomplett und fließend ist. Am Ende des Tages haftet die Firma für falsche Rechnungsstellung, Steuerabgabe etc.

Aber ein selbst geschriebener Connector für bspw das Shopsystem oder Marktplätze? Sicher denkbar. Sorge bereitet mir hier eher die Frage an welcher Stelle die LLMs anfangen werden die laufenden Kosten auf den User umzulegen. Ich möchte ungerne den Kostenfaktor JTL gegen einen ähnlich großen Kostenfaktor LLM plus Eigenarbeit tauschen.

Guter Punkt, den viele vergessen. Die KI-Abos sind aktuell noch stark subventioniert und spiegeln nicht die tatsächlichen Kosten, geschweige denn einen Gewinnaufschlag wieder.

 

[wawi-dl]

...

Und eine Eigenlösung via LLM sehe ich nicht. Nicht weil ich das nicht für möglich halte. Sondern weil hier einfach zu viele externe Gefahrenfaktoren reinspielen. In den letzten Jahren hatten wir OSS, Omnibus, aktuell Entsorgung etc. Hier eine rechtskonforme Lösung zu basteln würde voraussetzen, das man sich komplett in die entsprechenden Themenfelder einarbeitet, insbesondere weil der Informationsstand regelmässig unkomplett und fließend ist. Am Ende des Tages haftet die Firma für falsche Rechnungsstellung, Steuerabgabe etc.

Aber ein selbst geschriebener Connector für bspw das Shopsystem oder Marktplätze? Sicher denkbar. Sorge bereitet mir hier eher die Frage an welcher Stelle die LLMs anfangen werden die laufenden Kosten auf den User umzulegen. Ich möchte ungerne den Kostenfaktor JTL gegen einen ähnlich großen Kostenfaktor LLM plus Eigenarbeit tauschen.

100 Punkte, das sind genau die 2 Punkte die auch wir im Hinterkopf haben, man zunächst abwarten muss.

Stand heute "muss" man sich einarbeiten und alles abdecken, aber auch das wird nicht lange dauert, dass dies eine LLM abnimmt und man komplett sprachgesteuert geführt wird, am Ende ein fertiges System hat, inkl. aller erforderlichen Auflagen.
ABER, dennoch trägt man dann immer selbst das Risiko und man muss sich selbst kümmern.

Die Kostenfalle bei LLM kann schon noch kommen, erstmal alle in Abhängigkeit bringen, dann wie bei JTL jedes Jahr am Hahn weiter aufdrehen.

 

[MichaelH]

Und eine Eigenlösung via LLM sehe ich nicht. Nicht weil ich das nicht für möglich halte. Sondern weil hier einfach zu viele externe Gefahrenfaktoren reinspielen. In den letzten Jahren hatten wir OSS, Omnibus, aktuell Entsorgung etc. Hier eine rechtskonforme Lösung zu basteln würde voraussetzen, das man sich komplett in die entsprechenden Themenfelder einarbeitet, insbesondere weil der Informationsstand regelmässig unkomplett und fließend ist. Am Ende des Tages haftet die Firma für falsche Rechnungsstellung, Steuerabgabe etc.

Na ja, du musst aber zugeben, dass hier JTL auch alles andere als glänzt. (wie es bei Odoo aussieht - keine Ahnung)
JTL hat in den letzten 10 Jahren regelmäßig keine Lösung oder viel zu spät eine geliefert, womit man schon selbst eine Lösung zu finden hatte - und warum sollte man danach eine JTL-Lösung verwenden, wenn man schon eine hat ?

Meiner Meinung nach hat sich JTL in der Erfüllung von Lösungen für Großkunden, die sicherlich komplex sind, völlig verfahren, womit es keine einfache Lösungen mehr gibt, weil sie eben die Komplexität nicht erfüllen würden.
Diesen Eindruck hat man mittlerweile.
So eine Art von Eierlegender-Woll-Milch-Ferkel zu groß für Kleine und zu klein für Große.

Aber mal sehen was da konkret an komplett NEU von JTL daher kommt bis in X Jahren ?
Großes von der Connect habe ich nicht vernommen, war wohl mehr eine Connect für Mitarbeiter die sich ein paar Tage Urlaub vom Chef erschnorrt haben um sich bei Wein, Weib und Gesamt zu "connecten" ?
Oder was war denn nun die große Neuheit oder Ankündigung oder Sichtbare ?

 

[Morimus]

Die Kostenfalle bei LLM kann schon noch kommen, erstmal alle in Abhängigkeit bringen, dann wie bei JTL jedes Jahr am Hahn weiter aufdrehen.

Bei mir übernimmt Qwen3-32B lokal die Orchestrierung mehrerer spezialisierter Agenten.
Artikel anlegen, Produktbilder bearbeiten, Artikeltexte vorbereiten, E-Mails beantworten usw.

Technisch läuft das meiste über direkte, lesende Datenbankzugriffe sowie eigene MCP-Server und CLIs.
Die eigentlichen Aktionen werden über definierte Schnittstellen ausgeführt.

Das Sprachmodell muss also gar nicht die gesamte Arbeit selbst erledigen, sondern hauptsächlich Zusammenhänge verstehen, Aufgaben verteilen und die richtigen Werkzeuge ansprechen.

Das Ganze läuft auf unserer eigenen Serverinfrastruktur.
Die Hardware ist ohnehin vorhanden und für diese Aufgaben mehr als ausreichend.
Natürlich kostet auch der Eigenbetrieb Geld, aber wir haben keine laufenden Tokenkosten und sind nicht von den Preismodellen irgendwelcher LLM-Anbieter abhängig.

 

[Groundhog]

Ja, da habt ihr an vielen Stellen Recht. Ich arbeite seit 2009 mit JTL und seitdem hat sich viel getan, vieles aber auch nicht. Ich kann völlig verstehen, dass man Geld verdienen muss, denn auch JTL hat Mitarbeiter, Betriebskosten etc. zu bezahlen. Ich bin auch kein Entwickler, genausowenig wie ich ein BWL Studium hab. Ich bediene meine Zielgruppe aus einer Leidenschaft heraus und im Laufe der Jahre hat sich daraus ein Geschäft entwickelt, da so mehr oder minder läuft. Im Laufe der Jahre gewöhnt man sich an vieles, auch an Unzulänglichkeiten und Workarounds der Software. Vieles hab ich mir selbst beigebracht, mein Evo/Nova Child bau ich seit Jahren selbst - in den letzten Monaten dank KI auch besser und schneller.

Es gibt aber einfach Entwicklungen die mir Sorgen bereiten: Der Zukauf von Wissen und Funktionen in Form von Unternehmen ist nichts neues und durchaus legitim - aber ich möchte selbst entscheiden was ich nutzen will und nicht in einen Tarif gezwungen werden, der dann Basisfunktionen beschneidet um Cloud Lösungen zu verkaufen. Gleiches gilt für den Shop - der kann so vieles nicht, das dann von externen Entwicklern (vermehrt mit KI) nachprogrammiert und dann für monatliches Geld angeboten wird, dass man meinen könnte, es wäre Absicht sich darauf zu verlassen, dass Third Party schon die Lösung liefern wird.

Gleiches gilt für Gesetzesänderungen/Anpassungen...wenn es Third Party schafft, schneller als JTL Lösungen zu bauen, dann ist Komplexität der Gesetzeslage sicher nicht das Problem per se. Und mal ehrlich, wie lange konnte man in der Wawi erstellte Rechnungen wieder ändern, bevor man sie dann "festgeschrieben" hat - Rechtssicher...naja. Viele Lösungen sind heute auch noch immer nicht durchdacht oder gar hochwertig - man denke an die mittlerweile unendliche Funktionsattributliste für das Nachtragen von Pflichtangaben, etc.

Klar, die Nutzung von LLMs wird auch teurer - da stimme ich voll zu, aber ob ich jetzt mehrstellige Beträge in ein LLM oder Hardware investiere, oder in monatliche Gebühren für Wawi, Module, Shopplugins & Schnittstellenanbindungen ist dann Ermessenssache und ein Rechenbeispiel.

Vielleicht liegts auch einfach am Alter und so wie ich mich aus dem Windowsupdate-, Hardware- & dessen Lizenzwahnsinn verabschiedet habe, folgt Stück für Stück alles andere das mich belastet. Es betrifft also nicht JTL alleine, wahrscheinlich liegts einfach an mir.

 

[SebiW]

Und genau der Punkt ist auch wo es interessant wird: wie kriegt man solche Modelle sicher. Angriffe auf lokale LLMs sind nur eine Frage der Zeit.
(Indirect) Prompt Injection via Mail, RAG Poisoning, Tool Poisoning, Memory Poisoning...
Das überwachen lokal laufender Agents, inklusive Rechtemanagment, Micro VMs etc wird die größte Herausforderung in diesen Szenarien. Benötigt Berechtigungssysteme, Aktivitätsprotokolle, Überwachungstools. Und auch hier wieder die Frage: wer überwacht das? Liegt da dann die nächste AI Ebene drüber, inklusive separaten entkoppelten Systemen? Das nächste Wettrüsten mit Angriffsszenarien wie der aktuellen PHP Geschichte.

Die Automatisierung ist leicht zu bauen. Die Absicherung ist extrem schwierig. Und wird nur noch schwieriger je komplexer die zu erwartenden Angriffe werden.

 

[MichaelH]

Ja, da habt ihr an vielen Stellen Recht. Ich arbeite seit 2009 mit JTL und seitdem hat sich viel getan, vieles aber auch nicht. Ich kann völlig verstehen, dass man Geld verdienen muss, denn auch JTL hat Mitarbeiter, Betriebskosten etc. zu bezahlen.

Ja, wenn 2 Unternehmer nur 10 Mio Gewinn pro Jahr machen, dann wird es Zeit Hilfe zu holen. Das ist verständlich. Die Energiepreise fressen einem das Haar vom Kopf.

Es gibt aber einfach Entwicklungen die mir Sorgen bereiten: Der Zukauf von Wissen und Funktionen in Form von Unternehmen ist nichts neues und durchaus legitim - aber ich möchte selbst entscheiden was ich nutzen will und nicht in einen Tarif gezwungen werden, der dann Basisfunktionen beschneidet um Cloud Lösungen zu verkaufen. Gleiches gilt für den Shop - der kann so vieles nicht, das dann von externen Entwicklern (vermehrt mit KI) nachprogrammiert und dann für monatliches Geld angeboten wird, dass man meinen könnte, es wäre Absicht sich darauf zu verlassen, dass Third Party schon die Lösung liefern wird.

Im Shop war es schon immer so, wenn es die WAWI auch so könnte wäre es ja OK. Aber sie kann es eben nicht. Update-Zwang mit dem man sich Sachen reinholt die man nicht haben will.

Gleiches gilt für Gesetzesänderungen/Anpassungen...wenn es Third Party schafft, schneller als JTL Lösungen zu bauen, dann ist Komplexität der Gesetzeslage sicher nicht das Problem per se. Und mal ehrlich, wie lange konnte man in der Wawi erstellte Rechnungen wieder ändern, bevor man sie dann "festgeschrieben" hat - Rechtssicher...naja.

Den Haken konnte man schon fast immer setzen, nun ist es Zwang und dieser wurde erreicht mit einen recht eigenwilligen Lösungsansatz, der nun viele Folgeprobleme für die Entwickler bereitet - diesen Eindruck hat man. Denn eine versprochene Sammelrechnung die sagen wir mal "flexibel" sein wird ist noch in weiter Ferne und dies nun auch schon seit Jahren.

Vielleicht liegts auch einfach am Alter und so wie ich mich aus dem Windowsupdate-, Hardware- & dessen Lizenzwahnsinn verabschiedet habe, folgt Stück für Stück alles andere das mich belastet. Es betrifft also nicht JTL alleine, wahrscheinlich liegts einfach an mir.

Man erkenne Ziele der Software-Branche.
Software wird monatlich gemietet, selbst besitzt man gar nichts, somit alle Vorteile die sich für Hersteller daraus ergeben.
Und das abolute Ziel - die Software ist nicht mal mehr auf dem eigenen Rechner installiert, weil das für uns ja so toll ist und wir dies alle schon immer haben wollten.

 

[Groundhog]

Ja, wenn 2 Unternehmer nur 10 Mio Gewinn pro Jahr machen, dann wird es Zeit Hilfe zu holen. Das ist verständlich. Die Energiepreise fressen einem das Haar vom Kopf.

Ach was, wir sind ja nur pissed, weil wir am falschen Ende der Nahrungskette stehen 😀 😀 😀

 

[MichaelH]

Ach was, wir sind ja nur pissed, weil wir am falschen Ende der Nahrungskette stehen 😀 😀 😀

Wie sagt man ?
Mehr Geld bringt nicht automatisch mehr Glück und Zufriedenheit.