Hi,
I’m evaluation an ERP system for a small service company, 2 persons (1 FTE) doing invoicing, accounting, payment (SEPA with direct debit) and reconciliation. Both ERPnext and Tryton are on the short list. I already gave both a trial and found pros and cons for both.
I’d be eager to learn: Why should I choose ERPnext over Tryton? What makes ERPnext superior to Tryton?
Thanks in advance
We are also a services company using ERPNext
I looked through Tryton just now.
But I really liked the chronos feature of tryton and the tabbed navigation.
ERPNext is a much powerful solution with a lot of baked-in features. I am not sure how customizable it Tryton is, but I can say that boy, ERPNext is REALLY very customizable and configurable thanks to its metadata model (Python knowledge required)Also i found ERPNext (v13) to be much more user friendly than tryton. Reports in ERPNext are also much better + the dashboards.
While still checking it out, @chromonav took the words kinda out of my mouth.
I took a quick peek into the live demo, it seems to me that ERPNext is mightier, but much more complicated as well.
For the rest, and as far as I can assess from the quick check, I agree with @chromonav.
Though I have to add that translation and documentation seem a little lacking in German. As for the community… I found a number of unanswered threads or others that were started and answered, but never resolved, on here. Sad sad.
Kinda agree with it but, I have to note that people bond over problems they face. Sometimes yes the questions can go answered (Has happened for me). But that only means that no one has the same “itch” as you.
Finding people who are experienced with both Tryton and ERPNext, who can provide an unbiased comparison? Probably -very- difficult.
Back in 2016, I was looking for a new ERP career path. Tryton was a top contender, but I ultimately chose ERPNext.
After reading your post, I examined Tryton’s website, and -briefly- gave their demo a spin. My impression today is: “Wow…Tryton has improved a lot in 4 years !” Back in 2016, there wasn’t any Web UI option.
With only 10 minutes “experience”, here’s the best comparison advice I can give you.
+1 point for Tryton having a Desktop Client option! Their desktop client will likely have superior performance vs. ERPNext. That’s just the nature of Desktop App vs. Browser App. The browser must work harder, fetching both Data and Design from the web server. The desktop client only needs data, and as a binary executable, can really get efficient. Similar to how Excel on a PC is more-responsive than Excel Web or Google Cloud Sheets in a browser.
+1 point for ERPNext’s modern and responsive Web UI. ERPNext was born a web application. It transforms well on tons of devices. If you open on a phone or tablet, it’s very usable. It’s doing modern things like Flexbox, Grid, Vue.js, and more. But kudos to Tryton for making the effort. Their demo site does scale down to mobile, to my surprise. But it’s a very complex UI, and it’s going to feel quite “clunky” on a small device.
+1 for Tryton installation options. I remember installing in 2016, and it took about 5 minutes. I’m also very impressed (jealous) to learn they offer pre-made packages for Arch, Debian, Gentoo, etc. ERPNext installation is…not great (probably the nicest words I’ve ever used). If you search the forum, you’ll discover many hundreds of posts where people struggled with ERPNext installation.
+1 for ERPNext reporting. Tryton reports appear harder to use, create, and customize. ERPNext makes this very easy. And has more of them “out-of-the-box”
Customization “Potential” : Both are open-source projects. Both are built with modern languages (Python, JS). Assuming you’re an experienced developer, both are equally customizable. No limits.
Customization “Accessibility”: +1 point for ERPNext. You can perform quite a lot of Customization, directly in your browser, without being a programming guru. There’s a lot of flexibility for a beginner. However…with great power comes great responsibility! You can totally screw-up your ERPNext during Customization. I sometimes think it’s almost “too accessible” for the power users. They can end up breaking things. Because of Tryton’s dual Web/Desktop nature, I’m assuming it’s a lot harder for the average user to change any code.
+1 for Tryton’s sophisticated UI design. I really like how many widgets there are, and how they’re utilizing all the screen-space. ERPNext has few design widgets, mostly limiting your design to Column/Section breaks (or go 100% custom, which is a big endeavor). ERPNext struggles to display more than 4-5 columns in a grid, like when viewing Purchase and Sales Order lines.
Granted, Tryton’s UI is very traditional (1990s style, two colors). You’ll either love it or hate it. Regardless, it appears to offer more UI flexibility by default.
I cannot believe I’m actually typing this … but +1 point for ERPNext documentation. I greatly dislike ERPNext’s documentation (it’s one of my Top 5 complaints). However, Tryton’s online documentation is really minimal and abysmal. Let’s take Purchasing for example:
Neither one gives you enough information to actually operate in a production environment. But ERPNext clearly tries a lot harder.
Both support solid databases (MariaDB, PostgreSQL). It would be nice if either product offered us Choices. Still, you cannot go wrong either way.
Conclusion
If I had to describe each product:
ERPNext is a modern web application framework, where the #1 app is an ERP tool.
Tryton is an ERP system with a classic look, that offers both Desktop and Web UIs.
Tough decision, @jmiller. Personally, I suspect their capabilities are quite similar. If I had to choose again today in 2021? I’d probably still choose ERPNext. I think I’d have a hard time selling the Tryton UI, especially to newer generations of business owners.
That’s not to say ERPNext could not learn a lot from Tryton. It definitely appears to have big advantages in certain areas.
You can fix them! GitHub - frappe/erpnext_documentation: [DEPRECATED] ERPNext User Documentation. Please don't raise new contributions here.
Many thanks four this valuable comparison. This is exactly the kind of experience I’m seeking 
Parallel to asking here, I contracted a trustworthy consultant for an evaluation. Here is his report:
Last weeks I’ve spend some days evaluating ERPnext and Tryton. I read docs, searched the forums, watched tutorials, played with the demo installations available online and inspected the code publically available at this time. My primary aim was to understand the basic concepts of each software, as these are the parts which are near to impossible to change. (Whereas modules/doctypes can be added easily.) I might have missed some details, anyhow I’m confident that the central results are appropriate. Since I’ve been in touch with Tryton some years ago already, the test was more like I benchmarked ERPnext vs. Tryton. This is also why I did not list Tryton’s shortcomings here - which actually exist.
The test was conducted in early February 2021. Tested online ERPNext 13 beta something and Tryton 5.8.
Here is summary of the most relevant insights. TL;DR: I suggest to use Tryton. Tryton is more mature and has a better technical fundament than ERPnext. If you want detailed information, please get in touch at http://www.crazy-compilers.com
ERPnext’s seems to be more end-user/customer oriented, while Tryton seems to focus more on integrators. E.g. ERPnext has quite some functions (“onboarding”) making it easy to get started and testing, whereas in Tryton such wizards are rejected since there are other (manual) means to achieve the result.
In ERPnext you can customize quite some things via the WebUI, not coding is required. E.g. you can easyl customize reports by simple dragging “variables” to the right place. Anyway, one of the Videos warns about customizing DocTypes via the WebUI as this can conflict with updates. Anyhow this might ease prototyping.
For customizing Tryton there is a single programming language to know: Python (and some basic XML). Whereas for ERPnext you need to know both Python and JavaScript, as some of the functionality is done on the client side. The later also means you might have duplicate code, e.g. validating data must not only be done in the client.
Tryton is much more mature. ERPnext is lacking behind, e.g. my “standard” strings (like “My Settings”) are not translated to German, German charts of accounts is lacking information like account type, SEPA-support, while a central feature for 36 European countries, requires an external “app”, which again is quite huge and and beside SEPA also bings a lot of Swiss-specific extensions. Of course, ERPnext might catch up here in the next years. But given how long it took (in both ERPnet and Tryton) to get to the currents state, I’m afraid this will actually be some more years.
Most important IMHO are the basic concepts, which are hard to impossible to change. And this is where ERPnext drops far behind. Some examples:
('I. Vorräte - M','2021-01-28 00:03:29.024872','2021-01-28 00:03:31.265353','mycoolcompany@puppetmail.de', 'mycoolcompany@puppetmail.de',0,NULL,NULL,NULL,0,0, 'I. Vorräte','',1,'MyCool','Asset','Balance Sheet','EUR',0, 'B - Umlaufvermögen - M','',0.000000,'No','', 21,26,NULL,0,NULL,NULL,NULL,NULL)
ERPnext stores too much personal identifiable data, without any need to store this. E.g. many (all?) tables store timestamps and user, even tables like the user’s own settings. This seems to be build deep into the fundaments of Frappe and implies that removing personal identifiable data is hard up to impossible - which is a thread to GDPR compliance. There is also an “Activity Log” which login/logout timestamps and many other timestamps like when an invoice was created for a order.
I hope you didn’t pay to much for that consultant! If the biggest difference he can come up with is “varchar vs int”, he clearly knows nothing about either platform.
I would agree that ERPNext’s database schema is lacking. It violates many best practices. And it may suffer from performance issues with a large volume of data.
It used to bother me too. Over time I’ve learned to accept it, and focus on other challenges.
Despite the database deficiencies, ERPNext is a worthy choice. Like many great products, it can always be better. I’ve worked with expensive, proprietary ERPs with just as many issues (or more).
I disagree, he brings up valid points:
I have been checking the Tryton development from time to time since it’s fork from OpenERP, and my impressions are that there is a lot to learn from them:
To summarize: Both projects are high quality and can be reasonable choices for a company. Each system has its own unique challenges (this is true for any complex software), and each company has to decide for themselves which challenges are easier to overcome for their specific use case.
I think that it is important for us, the ERPNext community, to keep an open mind, and try to learn from others (including Tryton) to improve ERPNext as much as we can.
Don’t get me wrong, details matter. But, the observations made in that report are a dozen picked seemingly at random from literally thousands of consequential differences. Having good database schema matters, but int versus varchar primary keys doesn’t tell you anything about how Tryton and Frappe approach this problem differently. GDPR compliance is extremely important for many, but modification stamps are at most a tiny, tiny part of a very big question.
Compared to the content of this report, which seems stuck in minutiae without context, the broader descriptions you and Brian provide would be vastly more useful to someone actually trying to decide between what appear to be very different systems, each with strengths and weaknesses.
I have the same overall feeling about the discussion.
That said the GDPR compliance need some clarity for me. What would be an easy way to overcome that. Couldn’t we add a field to each user with a unique random sequence of number, so when a European user that want to remove all mentioned of ID, we can remove user without having to worry about all the “modified by” / “created by”.
What do you suggest?
You can already do that. I don’t know exactly what the GDPR requires, but if you change the email address in the User document to something random/non-identifying it will replace the identifying value in all “modified by” / “created by” fields.
I think not having a strongly enforced db schema (at the DB level) is a feature. It makes it (potentially) easier to tear components apart in the future into services and implement classic domains with boundaries like an “order service” or a “customer service” or reimplement the one you need optimized for speed.
If order needs concistency with customer, that’s de responsability of the order domain, based on what the customer domain manifests (“event sourcing”). Would a strong relational schema be enforced, updating the customer domain would generate side effects in the order domain.
Hence, the order domain cannot control it’s own domain any more. Unmanagable complexity hell ensues and blocks appropriate domain innovations (according to DDD theory). Odoo is at that dead end, somehow.
edit: I also want to add, that business reality is messy, so in principle slightly leaning towards “copy” (over “reference”) actually accounts for some of that messiness pretty well, circling back to DDD principles, here as well.
Frappe gives doctype designers a lot of flexibility on database structure. I am far from being an SQL guru, but as an amateur I see advantages and disadvantages to that. Authors can define primary keys to be pretty much anything they want. I believe the default is a ten-byte hexidecimal hash. In practice, however, most ERPNext doctypes use human readable names of some sort or another. There are advantages to this (such as more semantically transparent api calls), but also disadvantages (such as the gaps that can emerge in documents named by numerical series when drafts are deleted).
It’s not that these details aren’t important. They’re the most important thing. But, they’re also extremely contextual, with hugely different effects emergent from subtly different needs and circumstances. It’s so, so, so hard to make meaningful comparisons between two platforms on the basis of these differences, likewise, because there just aren’t that many people who know both ERPNext and Tryton deeply enough to make a comparison sufficiently comprehensive.
That said, it’s been very interesting to hear people’s experiences. The two projects both seem extremely valuable, and I’m not sure it’s possible for any user to make a genuinely educated decision between them without first devoting serious time and energy understanding both.
Looks like there is a tool:
https://docs.erpnext.com/docs/user/manual/en/setting-up/personal-data-deletion
hello, I’m back on this topic with another question.
On Tryton, I use to support communities who develop their own product as a derivated code from Tryton. They add industry specific modules and create a adequat business model to support it. Successful examples are GnuHealth, LIMS, Coog, OpLibris etc…
Are there similar examples based on ERPNext ? How easy is it to derive a specialized product from ERPNext and keep it in synch with the main project over versions ?
Thank you for any advice.
Hi Dominique - That is a great question, and possibly worth re-posting in its own thread.
Short answer: Yes, this happens all the time. ERPNext was designed and intended to support the concept you describe: developing “bolt-on” solutions.
How easy? The answer varies significantly with the complexity of your addition. Adding a few new data structures and triggers? That is extremely easy. But as your new product grows, so can the complexity.
It’s difficult to give advice, because there are so many approaches and considerations. If the developers write good documentation, follow best practices for change management, and clients only upgrade during planned maintenance windows? Then I believe it’s no more difficult than any other ERP I’ve encountered.
Just adding my experience.
I’m not a programmer yet I can do some customization using front-end gui and clieant/server scripts. The problem I mostly had was the programming (py, js) itself. Not the structure of frappe nor erpnext.