Hi, I’m interested in some comparison between Tryton and Dolibarr. The later is a „competitor“ in a project and I want to convince the project to use Tryton.
They are both free workable software.
Do you know what the key requirements are and how decision makers think ?
May be one doesn’t meet requirements or both succeed or fail.
Of course, by definition, we all prefer Tryton here, but that’s of no help.
If both can be used, the project may choose the best partner because in their mind, the best partner made the best choice regarding the product.
Exactly the question I have been pondering for literally years, watching the development of both, after trying out numerous open source ERPs, all lacking in some aspect.
Dolibarr = php + mysql. Lots of functionality (probably the most comprehensive for a free ERP) but built on a legacy codebase with a huge amount of baggage but also a lot of “hooks” to add-in customisation without touching core code. While php allows non-pro developers/diy-ers to have a go, despite having years of php experience with Zen Cart, I found it very difficult to get to the nub of each problem I encountered in Dolibarr.
In my limited experience it is needing a massive effort to move into this century code-wise/use a framework and so far there appears to be still no plan.
A related discussion:
On the other hand Tryton, modern codebase, less functionality (I’m guessing) and much harder to modify for the occasional/non-professional programmed/inexperienced diy-er.
In the end there is no way to avoid the work involved /invested/wasted in trying out/setting up a test solution in your real business environment to discover the show-stopper holes in functionality and whether they are viable to get coded/fixed.
In short I would prefer Tryton for the modern codebase, but your business needs will determine what extra is required/what will be the additional costs to be your complete solution.
I think the most efficient path is to use a local partner to look over your business and highlight what is outside current functionality.
The weakest point of Dolibarr is accounting for most localizations.
Even more important IMHO is software quality. Dolibarr is much less abstract then Tryton is, see this post in the German Dolibarr forum for some more details. Summary:
- No abstract data model
. No abstraction for databases, plain SQL is used instead
- Model and View are intermixed
- HTTP and HTML build deep into the code.
As an result:
- more effort is required for implementing extensing
- assumed its complicated to change existing behavior
- most probably not possible to change existing views.
One of the things I love about Tryton, is the fact that I can use it everywhere. I see Tryton in itself not as an ERP system, but a business framework you can build upon. It’s a very modular base with:
- communication layer for the database building advanced queries and takes all the responsibility for data integrity
- user management and advanced MFA authentication
- modularity from the ground up
- templating engine to make it easy to create your own documents
- workflow system
- email system
- trigger system, execute actions based on changes somewhere else in the system
- task scheduler
- queues to offload long running tasks
- easy extendible by modules which can depend on each other
- programmed in Python, worlds most stable programming / scripting language
Modules and their behavior makes that it’s called an ERP system. But I have also created a sort of PLM system for assets which are lended and moved around in the organization. Just tracking of the assets and what happened to it during it’s lifetime. No sales, purchases or accounting are involved.
Sometime I refer to Tryton as a container vessel. The vessel has everything to stay afloat and keep the crew happy, but also all the equipment needed to navigate the ocean and stay on course. Modules are the containers you load onto the vessel. When secured and fixed to the vessel, you sail away enjoying the weather and view. When you are missing something or need an upgrade or changes or need a new container, you go back to the port to load that container do the upgrades etc.
Yeah, I know it’s a bit philosophical but most understand the idea. You can also see clearly where the costs are, in the port when loading a new container or make changes etc.