Dolibarr vs Tryton

Hallo zusammen,

ich bin gerade dabei, eine ERP-Lösung für meine kleine Firma zu suchen. Dabei sind Dolibarr und Tryton in der näheren Auswahl.

Was sind den Vor- und Nachteile von Dolibarr gegenüber Tryton? Ihr braucht kein Blatt for den Mund zu nehmen :slight_smile:

Herzlichen Dank für eine rege Diskussion

Hallo,

welche Lösung im konkreten Einzelfall die geeignetere ist, hängt maßgeblich von den Anforderungen ab. Da darüber nichts bekannt ist, wird es schwierig werden, hier eine hilfreiche Antwort zu geben. Wie sind denn genau diese beiden Lösungen in die Endauswahl gekommen?

Hallo,

ich kenne Tryton noch nicht aber zu dolibarr kann ich sagen:

  1. Installation: top (Windows-Version ist einfach und ohne großes Technikwissen möglich)
  2. Updates: funktionieren meist auch einfach mit integrierter Datenmigration.
  3. Standardmodule: sind brauchbar gut aufeinander abgestimmt. Sollte jedoch etwas fehlen, fängt der Ärger an… z.B. ist Dolibarr nicht in der Lage, mir eine Liste zu generieren, die alle zu bestellenden Rohmaterialien und die dazugehörigen Lieferanten auflistet. Das ist ja eigentlich die Basisfunktion um vernünftig einzukaufen (die Liste müsste alle eingepflegten Kundenbestellungen und alle bereits getätigten Lieferantenbestellungen sowie den Lagerbestand berücksichtigen).
  4. Das Produktionsmodul ist für uns noch völlig unbrauchbar. Ist aber eigentlich Kern eines ERP-Systems
  5. Forum: ist völlig tot. Erwarte hier keine Hilfe. Du schreibst hier normalerweise Monologe
  6. Zusatzmodule: Existieren viele, funktionieren in der Regel aber NICHT, weil die meisten Entwicklungen eine individuelle Lösung realisiert haben, die Ihr Problem löst aber nicht in die Breite geht. Hier habe ich schon einige 100-Euro in den Sand gesetzt.
  7. Wichtigste Funktionen sind mit sogenannten globalen Defines zu aktivieren. Hier muss man Glück haben und mal was aufschnappen, wie z.B. das „BOM_SUB_BOM“ das in einem Forenbeitrag vor ein paar Tagen genannt wurde. Dass man hier wichtigste Feature noch aktivieren muss bringt mich regelmässig zum durchdrehen. Aber die Entwickler haben grossen Spass damit, gute Features zu verstecken. Sie könnten es ja aktivieren und der Nutzer kann es dann abschalten, wenn er es nicht braucht. aber egal.
  8. Die Dolibarr-Entwickler leben meiner Meinung nach auf einem fremden Stern und werfen ab und an mal einen SW-Stand auf den Planeten Erde. Mir persönlich fehlt die Möglichkeit Bugs und Features vernünftig melden zu können. Scheinbar soll man das direkt im github tun. Weiss nicht, ob damit jeder klar kommt.
    Wenn du nicht selbst php programmierst oder einen Nerd in der Belegschaft hast der rudimentäre php-Kenntnisse hat, kann dich dolibarr in die Verzweiflung treiben.

Ich bin seit Version 3.7.1 (2015) mit Dolibarr unterwegs und meine Mitarbeiter sind oft sehr verärgert über fehlende Features oder fehlende Übersichten. Aber das ist halt der Preis um kostenlose Tools nutzen zu können.

Gruß
scaleo

1 „Gefällt mir“

Hallo Michael,

hier im Dolibarr-Forum wirst Du wahrscheinlich wenig Leute finden, die sich näher mit Tryton beschäftigt haben. Das habe ich auch nicht. Ein Unterschied ist, dass Dolibarr auf dem Webserver läuft und mit praktisch jedem Browser verwendet werden kann. Tryton hat ein Client-Server-Modell, d.h. man muss auf jedem Arbeitsplatzrechner zunächst die Client-Software installieren. Das muss nicht schlecht sein, aber ich schätze es sehr, dass ich Dolibarr mit jedem Browser unabhängig vom installierten Betriebssystem bedienen kann.

Wie Joachim schon geschrieben hat, wäre es gut zu wissen, wie die Anforderungen sind. Was macht Ihr denn so in der Firma (Handel, Produktion, Dienstleistung, Kunden-Support …)?

Meine Erfahrungen sind etwas anders als die von Scaleo. Zu den meisten Fragen habe ich hier im Forum hilfreiche Antworten erhalten. Zusatzmodule habe ich noch nicht benötigt und würde ich auch nicht kaufen, wenn ich sie nicht vorher ausprobieren kann. Die angesprochenen Konstanten sind deswegen nicht in der Standardkonfiguration enthalten, weil es meist entweder Beta-Features sind oder eher ausgefallene Features, die die Mehrheit nicht benötigt. Sie sind hier: Setup Other - Dolibarr ERP CRM Wiki dokumentiert, man muss also nicht warten, bis sie jemand zufällig erwähnt.

Dolibarr verwende ich seit knapp drei Jahren. Ich bin primär im Handel tätig, habe aber auch etwas IT-Hintergrund. Die Grundfunktionen haben auf Anhieb funktioniert, später auftretende Probleme habe ich meist relativ schnell lösen können.

Hallo @priojk,

Es geht um eine generelle Auswahl für eine Gruppe von unterscheidlichen Organisationen: Vereine, Genossenschaften, GmbHs. Sie vereint, dass sie im großen Feld der „Nachhaltigkeit“ unterwegs, ansonsten sind sie sehr unterschiedlich.

Daher interessierer ich mich mehr für konzeptionelle Unterschiede als für Unterschiede in den Details bei Funktionen: Wo ist Dolibarr Tryton technisch überlegen? Wo hat Dolibarr besser Konzepte (welche)? Etc.

Die Antwort von @scaleo geht genau in diese Richtung — auch wenn sie eher die Nachteile von Dolibarr beschreibt :wink:

Gruß
Michael

Danke für die Einschätzung. Du scheinst ja recht unzufrieden mit Colibarr zu sein. Magst Du erzählen, weshalb Du es trotzdem weiterhin einsetzt? Also: Welche Vorteile siehst Du bei Dolibarr?

Nur zur Info: Tryton bietet seit einigen Jahren auch eine Web-UI, siehe https://demo.tryton.org. Man muss sie jedoch zusätzlich installieren und sie basiert auf node.js. Interessant ist jedoch, dass sie letzdenlich die Funktion des Desktop-Clients ziemlich gut ins Web umsetzt: Die Definitionen der Sichten liefert wie beim Desktop-Client der Tryton-Server.

Hi,

ja gut ich stecke vielleicht auch in einer besonderen Rolle. Wir können uns aktuell noch kein professionelles ERP leisten und sind auch mit unserem Umsatz so an der Kante, an der sich ein ERP überhaupt lohnt. Jedoch haben wir so komplexe Elektronik-Produkte (mit bis zu 600 Einbauteilen), die ein ERP zwingend erfordern.
Dolibarr ist natürlich viel besser als Exceltabellen. Jedoch bringen die Module wirklich nur das allernotwendigste mit, was ERP Systeme sonst können. Und das sollte man schon auch wissen, wenn man vor einer Entscheidung wie dieser steht.

Mein Frust kommt halt auch daher, dass z.B. mit jeder Version die Statistikbalken neue Farben und Formen bekommen, während das System mir aber immer noch nicht sagen kann, was ich bei Lieferant XY alles einzukaufen habe, damit ich alle laufenden Aufträge abarbeiten kann.
Aber mir ist ja auch klar: es ist alles für umsonst…
und ich weiss: ich kann’s ja besser machen, wenn ich nicht zufrieden bin.

Nur hier „heile Welt“ und „tolles Tool“ vorspielen, danach ist mir halt auch nicht zu Mute.

Hallo Michael,
bei der integration von Dolibarr sollte/muss jemand greifbar sein, der php Kenntnisse hat. Denn es gibt einige Themen über welche man bei der Integration des ERP´s stolpert und es ohne php nicht weiter geht.
Der theoretische Funktionsumfang welcher in Dolibarr zur Verfügung steht, steht in meinen Augen mittelgroßen ERP System (wie z.B. BIOS, Tryton, ERP-Next…) nichts nach. Jedoch ist eben leider nicht sichergestellt, dass alle Module einwandfrei laufen. Somit sind wir wieder beim Thema KnowHow in php um Fehler zu beseitigen.

  • Die simple Bedienbarkeit und geringe Ladezeiten, wenn dann mal alles so läuft wie man es sich vorstellt, ist gut.
  • Das Einlernen von Mitarbeitern ist gut machbar.
  • Wenn php Kenntnisse vorhanden sind, ist die Anpassbarkeit (Bedienung und auch das Verhalten) von Dolibarr sehr gut (durch das Hooksystem).
  • geringer Ressourcenbedarf
  • aktive Community (zumindest im Französischen Raum oder in englischer Sprache)
  • OpenSource Änderungswüsche (über PullRequests) werden relativ schnell integriert. Dies führt zu einer sehr schnellen Weiterentwicklung hat jedoch auch den Nachteil der schlechteren Qualitätssicherung.

Das sind so die Erfahrungen welche ich in den letzten Monaten gemacht habe.
Wir werden Dolibarr wahrscheinlich in unserer Firma im laufe des nächsten Jahres „produktiv“ integrieren.
Mein Tipp: Eine klare Beschreibung des benötigten Umfangs, eine gute Migrationsstrategie aus bestehenden System und eine ausreichende Simulationszeit für alle Prozesse welche in den Firmen, Vereinen, usw… benötigt werden muss bei Dolibarr wie auch bei jedem anderen System eingeplant werden.

@scaleo
Hallo scaleo,
unter Produkte | Leistungen → Nachbestellung → Filter auf „Theoretischen Lagerbestand verwenden“


Dort werden alle Produkte aufgelistet welche für laufende Aufträge noch benötigt werden (also sich nicht genügend im Lager befinden). Ich bin aktuell dabei, die Beschaffungsansicht zu erweitern um auch direkt Produktionsaufträge daraus zu erstellen d.h. ist das Screenshot nicht 1:1 wie bei Dir.

Mit freundlichen Grüßen
Christian

Hi Christian,

OK, ich sehe Du verwendest bereits V17. Ich hatte die Nachbestellfunktion auch schon ausprobiert, aber sehe ich da auch den Lieferanten? Ich werde mit V15.0.3 nochmal testen.

Wie kann man diese pull-Request nutzen? Gibt’ dazu irgendwo eine Erklärung?

Wir bräuchten z.B. bei den Kundenaufträgen die Möglichkeit einen Rahmenauftrag einzutragen und dann mit Kunden-Abrufen zu arbeiten.

Auch bei der Preisgestaltung sollten wir Staffelpreise in Abhängigkeit der Bestellmenge hinterlegen können.

Oder wenn ich eine Rechnung stelle, sollte ich 2 oder mehrere Lieferungen auf eine Rechnung zusammenführen können.

Das sind alles Dinge, die wir nicht hin bekommen.

Grüße
scaleo

Hallo scaleo,

  • ja, die Lieferanten sieht man da auch und man kann sofort eine Bestellung daraus erzeugen.
  • Für PullRequests muss man selber seine gewünschten Änderungen programmieren und diese dann durch einen Moderator im GitHub in Dolibarr integrieren lassen. Dies ist glaube ich nicht, dass was Du suchst :wink: .
  • mit Rahmenverträge habe ich bisher nichts zu tun gehabt und kann Dir das leider nicht weiterhelfen.
  • Staffelpreise sind meines Wissens im Produkt einzugeben.
  • Das zusammenführen von Rechnungen ist meines Wissens möglich, jedoch weiß ich darüber in Dolibarr noch zu wenig.

Gruß Christian

Tryton habe ich auch mal ausprobiert und wieder aufgegeben, weil es da Null Installationsanleitung gab.
Außerdem fand ich die UI sehr umständlich in der Handhabung. Habe auch Odoo ausprobiert.- Das ist schick, kann aber kann auch nicht alles und ich fand es auch unübersichtlich Preisgestaltung, da man nie weiß was alles an kostenpflichtigen Modulen noch auf einen zukommt, wenn man sich drauf einlässt. Dann stieß ich auf Doilbarr und bin seither begeistert, weil so ziemlich alles an Grundgerüst dabei ist was man so braucht. Aber natürlich erfüllt auch Dolibarr nicht alle Wünsche. - Das tut auch SAP nicht, Und vermutlich auch alle anderen ERP nicht. Da hat jedes System seine Stärken und Schwächen.
Bei Dolibarr stört mich persönlich, dass es oft zu viele Mausklicks braucht um sich drin zu bewegen. Aber das wird von Version zu Version gerade besser. Die Installation/Updates funktionieren eigentlich ohne Probleme. Praktisch finde ich auch dass es via App genutzt werden kann. - Ein Schwachpunkt bei Dolibarr ist noch der Dolistore. Da fehlt manchmal die Qualitätskontrolle. Und nsatürtlich könnte auch die Hilfe besser sein. Aber da muss man, statt drüber schimpfen, sich als Open Source Nutzer auch mal an die eigene Nase fassen und sich mit für Hilfetexte engagieren. Das geht auch ohne Programmierer zu sein.

Herzlichen Dank an alle, die geantwortet haben. Es scheitn ja die Skepsis zu überwiegen.

Ich habe mir Dolibarr inzwischen „unter der Haube“ angesehen und mich dagegen entschieden. Die SoftwareQualität von Dolibarr ist m.E. leider zu schlecht — sorry, das so direkt sagen zu müssen.

(Leider darf ich als neuer Nutzer nur zwei Links setzten, daher müsst die URLs der anderen Beispiele selbst zusammenstellen.)

  • Keine Abstraktion des Datenmodells

  • Keine Abstraktion der Datenbankabfragen, stattdessen werden SQL-Abfragen per String-Konkatenation erstellt:

    • Beispiel 1: class to manage accounting accounts 16.0.0/htdocs/accountancy/class/accountingaccount.class.php#L189-L205) (Buchhaltungskonten)
    • Beispiel 2: Abfrage des aktuellen Geschäftsjahres
    • Security-Bewertung: SQL-Injection ist eine häufige Schwachstelle in Web-Anwendungen. Ein Programmierstil, der SQL-Abfragen nutzt und dabei auch noch String-Konkatenation verwendet, fördert solche Schwachstellen. Auch wenn die offiziellen Module hier einen Programmierstil pflegen, der SQL-Injection verhindert, steht zu befürchten, dass exteren Module (aus dem „Dolistore“) anfällig für solche Angriffe sind.
    • Tryton: Die Datenbanken werden über eine Abstraktionsschicht angesprochen.
  • Mischt Model und View

    • Beispiel: Datenklasse enthält den Namen des zu verwendenten Icons 16.0.0/htdocs/accountancy/class/accountingaccount.class.php#L49-L51.
    • Tryton: Definiert Views gesondert.
  • HTTP und HTML sind tief im Code eingegraben

    • Beispiel 1: Im Module für Buchhaltungskonten wird der HTTP-Location-Header gesetzt /16.0.0/htdocs/accountancy/bookkeeping/listbyaccount.php#L458
    • Beispiel 2: HTML-Formular in Module für Buchhaltungskonten 16.0.0/htdocs/accountancy/bookkeeping/listbyaccount.php#L593-L1172
    • Tryton: Es gibt einen Desktop-Client, der nicht Web-basiert ist, und einen Web-Client. Bei letzterem wird die Umsetzung der o.g. Views in HTML durch einen eigenen Web-Frontend-Server gemacht.

Bewertung:

Eine Folge hiervon ist auch, dass es

  1. wesentlich aufwändiger ist, Erweiterungen zu erstellen
  2. denn man muss viel mehr Code schreiben, der zudem auf niedriger Ebene und damit fehleranfälliger ist
  3. vermutlich schwer bis unmöglich Änderung an Bestehendem zu machen.
  4. Ich bezweifle, dass es möglich ist, bestehende Formulare/Views zu ändern, also z.B. eine Spalte hinzuzufügen oder weg zu nehmen. (Ich habe es nicht im Code geprüft, aber da die Formulare hard-coded sind, sehe ich keinen brauchbaren Weg.)

Das wiederum bedeutet, dass die Kosten für Anpassungen bei Dolibarr wesentlich höher sein werden als bei Tryton.

Das schöne an Open Source Software ist ja, dass jeder seine eigene Wahl an Hand seiner eigenen Kriterien treffen kann. Wobei ich die angesprochenen Punkte grundsätzlich anders bewerte und gewichte.

Ja, die Hierarchien der Buchungskonten sind über id’s abgebildet. Das heisst aber nicht, dass zwischen anderen Objekten nicht aufwändigere Verlinkungen bestehen. Gerne einen Blick auf die ziemlich einzigartigen Funktionen des Moduls „Projekte“ werfen, das sich in der Praxis als extrem hilfreich erwiesen hat.

Abstraktion von Datenbankabfragen per ORM hat Vor- und Nachteile, für mich wäre es kein must have. Was die Sicherheit angeht: Das bestehende Bug-Bounty-Programm fördert nicht mehr viel Neues an Lücken zu Tage. Jeder neu committete Source-Code wird zudem einer zusätzlichen automatisierten Sicherheitsprüfung unterzogen. Und im laufenden Betrieb ist die Administrator-Ansicht von Dolibarr zu den detaillierten Sicherheitseinstellungen einschließlich konkreter Handlungsempfehlungen ziemlich einzigartig.

Zu Model und View: Wenn ich jedem Buchungskonto ein Icon zuordnen kann, muss ich den gewünschten Identifier des icons ja irgendwo in der Datenstruktur ablegen. Kann man sicher auch anders lösen, die genaue Umsetzung wäre jetzt nicht meine Prio.

Grundsätzlich finde ich persönlich Server-generierte html-Seiten, wie dies bei php-basierten Systemen der Fall ist, für ein ERP-System eine angemessene Technologie. Tryton nutzt den früheren/alternativen Ansatz des Fat/Rich Clients und hat dann irgendwann zusätzlich das Web-Frontend als quasi zweiten Client nachgelegt. Das sind zwei Clients, die zu pflegen sind und die Seiteninhalte müssen per XML und Templating erstellt werden, statt html zu nutzen. Kann man machen und je nach Vorerfahrung wird es da unterschiedliche Präferenzen geben.

Bei Tryton muss man sich halt an das etwas exotischere Tooling gewöhnen. Source-Verwaltung ist per Mercurial genauso gut möglich, wie mit Git, das aber viele Entwickler ohnehin beherrschen, ohne sich einarbeiten zu müssen. Von 16 Open Source ERP-Systemen ist Tryton zumindest das einzige, das auf Mercurial setzt.

Ansonsten kann man, wenn man strenge Source-Code-Regeln haben möchte, die sogar per Compiler geprüft werden, ja auch in Richtung Java schauen, und sich z.B. für Apache OfBiz entscheiden. Die Java-basierten Systeme haben dann nur u.a. den Nachteil, dass die Oberfläche entweder Swing-basiert ist und damit nicht/nur schwer auf einem Smartphone oder Tablet darstellbar ist. Oder es gibt einen JavaScript-basierten Client, der mit React oder Angular als Frameworks dann aber zusätzliche eigene Komplexitäten generiert.

Und noch etwas zur Modulerstellung: Mit dem in Dolibarr integrierten Modulgenerator, dem Konzept der Integration neuer Funktionen in das bestehende UI (z.B. mit zusätzlichen Tabs und Menüpunkten), dem System aus Hooks und Triggern und nicht zuletzt der einfachen Installation neuer Module per Knopfdruck ist Dolibarr m.M.n. bestens auf Erweiterbarkeit ausgerichtet. Ich wäre mir da nicht so sicher, dass der Anpassungsaufwand höher als bei den anderen Systemen ist - ganz im Gegenteil.

Am Ende zählen wie gesagt die persönlichen Präferenzen. Ich selbst habe bisher die meisten Erfahrungen mit Dolibarr gesammelt, auch wenn ich viele andere Systeme kenne. Es wäre daher interessant, später mal einen Erfahrungsbericht aus der Praxis zu bekommen, ob sich die Einschätzung geändert hat, nachdem das erste System installiert und das erst Modul entwickelt wurde. Am Ende kommt ein sportlicher Wettbewerb zwischen den Lösungen allen Open Source Systemen zugute.

In diesem Sinne viel Erfolg,

Joachim