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 Tryton and ERPnetxt 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 Tryton over ERPnext? What makes Tryton superior to ERPnext?
Your requirements can be fully managed with our standard modules. It will be great if you can share the country your company is based on to see if Tryton has the localization chart by default or you will need to create your country localization or setup your accounting manually.
This should be an important point to take the decision.
Sincerely I do not know enough details of ERPNext to give this comparison. I know they use a similar stack (Python and PostgreSQL as backend) but IIRC they only have a web interface, while on Tryton we have a desktop application and a web interface also.
I will try to summarise some good aspects of Tryton:
We prioritize quality over quantity: we may have less features but we focus on implement them very well and complete
jmiller asked me for an evaluation. Here is my 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.
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:
ERPnext is a monolith, it is huge and complex: Alone the source is 20MB ERPnext plus 14 MB for Frappe framework. Plus additional requirements nodesjs and redis. tryton and all core modules total to 13 MB - and one only installs the required ones. While this is only a rough comparison, it gives some idea. And to emphasis: Just the Frappe framework is as huge as entire Tryton.
Installing ERPnext is much more work, as there are many more components to be installed. For Tryton you just need Python - not even a DBMS is required for first steps and tests.
ERPnext used strings (varchar) as primary keys instead of integers. This not only imposes quite some problems when changing entries, but also is slow and increases storage and memory consumption. The later is esp. true, since every table contains a “modified-by” and “owner” user-id as a string. ('I. Vorräte - M','2021-01-28 00:03:29.024872','2021-01-28 00:03:31.265353','firstname.lastname@example.org', 'email@example.com',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)
As a result of using strings as primary keys: If someone renames an object while working with it, there are also strange effects - because the name is in the URL, and that is no longer valid.
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.
In Tryton you can customise most reports with LibreOffice or an text editor.
Tryton also uses these fields for every table:
id as primary key,
but we use integer for id and uid and timestamp(6) for the dates. id has default database INDEX and uses sequences. The uid refers to the res_user table, but is not JOINT for some reasons, but Tryton disallows the deletion of res_user entries.
Since this is the Tryton forum, I’m also adding some major drawbacks of Tryton. As you can see, these critic points are quite different to those about ERPnext. While for ERPnext the software fundamentals are deficient, for Tryton it’s “only” the environment.
Missing focus on first-time user/evaluators and UX. This can be seen by
Tryton having barely setup wizards (Recently I suggested some simple ones, which have been rejected since this can be done otherwise),
common feature request being rejected instead of offered as an “contributed” module (e.g. getting prices from articles in invoices, tax-included prices)
recent discussion about hiding fields on views
Your mileage may vary, of course
The scattered and antiquated development tooling (mercurial, codereview, roundup) is a obstacle for contributions. Even simple doc changes are a lot of effort, requiring learning new tools. And IMHO Tryton is in urgent need of contributions, esp. for documentation.
As a result, many contributors are maintaining theri own copy of Tryton on github or gitlab - which again is scattering the community.
Documentation and tutorials are also scattered. (GSoD docu is still not integrated)
A common place to collect “contributed” extensions is missing.
I may understand that our tools are not the usuall one but we use them because people that regualiry commit on the project prefer them. We are not gonna change it and we found that this is not really a problem for people that want to contribute.
Having said that I’m always happy to help somebody with the contribution process, so feel free to ask on our forum and we will provide as much as help as possible.
If you plan to contribute to our documentation and you do not want to deal with or tools I offer myself as bridge between them. In order to do so please create the files following our guideliness, delivery them to my PM box and I will upload to our review process.
Please note that reviewing all the patches that should be included takes time. We can not avoid reviewing patches without lowering our quality. IMHO lowering the quality is not something that will benefit the project.
Having said that, if you want to speed up the process please join the review process.