ERPNext vs. Tryton

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.

3 Likes

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.

3 Likes

Looks like there is a tool:

https://docs.erpnext.com/docs/user/manual/en/setting-up/personal-data-deletion

3 Likes

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.

1 Like

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.

  • First, can develop your own “Apps” that coexist with ERPNext. You can create new data structures, code, and designs. There are also mechanisms to modify and integrate with the official code. There is a lot of variety.
  • Second, because ERPNext is open source, you can always fork the official code, if you are willing to maintain that.

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.

2 Likes

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.

Biggest concern right now is the performance, specially for retail environment, is not negotiable to have more than 15 seconds waiting for invoices to process, hopefully we can gain some improvements in the near future.

Slow performance submitting invoices POS - ERPNext - Discuss Frappe/ERPNext

Yes, it is fairly feasible with Frappe/ERPNext, examples include Education, Agriculture, Healthcare, etc. However, the governing approach is different from Tryton’s: instead of independent vertical solutions, the modules are merged back into the core and have the same lifecycle as the main ERP. Of course the merits of either approach are debatable

Great topic and thread. Picking an ERP is such a perilous path. Especially, now, that we have a plethora of open source products.

As a framework, beyond technology and features, I look for a couple of things:
a. Size of community - Frappe’s community is huge - and helpful.
b. Size of commercial vendors - this is an often overlooked aspect. Open source projects NEED commercial vendors, in order to remain viable. These vendors NEED to contribute back to the community. Commercial vendors living off the ‘halo’ of open source are like the bees. Here too Frappe seems to have a lot of commercial vendors. Though perhaps more can be done to nurture and grow this community.

If either of the above is lacking, the community will not sustain in the long term. (btw, this is true of commercial products as well). If I install erpnext, I need to know that my company can buy/find/google support, if I move on.

In terms of features and technology. The DB design was a bit puzzling - used as I am to GUID/UUID/Sequences for normalization. But thats a learning curve rather than a hinderence. Performance in peripheral high volume systems (eg POS) might get affected. I didn’t see any issues.

In terms of functionality - ERPnext does need to grow. Typically functionality only grows with experience. No amount of design can cover all eventualities. People pay crores for SAP/Oracle because they have 40+ years of bug fixes and business scenarios. (also thousands of companies supporting it)

Frappe and Tryton are on par in terms of the above framework. I think Frappe’s general movement towards being a low code platform puts it above Tryton. I have done 3 small implementations and had to use minimal dev support. In the longer run, ability to quickly add functionality will help users succeed.

1 Like

Thank you for your detailled answers regarding derivated products with ERPNext.

My next question is related to e-commerce.

Tryton community rejected the Odoo way which serves shop pages directly from the ERP GUI. Lack of flexibility.
Tryton has experimented several possibilities to integrate with e-commerce.
A long time ago, connectors to Majento, Prestashop and others
Then Flask based e-commerce development with tryton-flask
Last integration with Vue StoreFront. or considering the ShopInvader approach.

What is ERPNext strategy toward full range e-commerce ? How does it compare ?

Thank you again for you enlightning standpoints.

ERPNext has a built-in public-facing website CMS with ecommerce capabilities. The ecommerce part is…decent. For something simple, I think it works fine, but there’s nowhere near the level of polish found in dedicated projects.

There are connectors for Shopify and Magento that people use with varying degrees of satisfaction. There was some talk in the community about building a Vue StoreFront connector, but I’m not sure if work has started.

To take a stab at synthesizing some of the discussion here (and with apologies for my very limited knowledge of Tryton), it seems like Tryton focuses more on being an application whereas Frappe/ERPNext focuses more on being a framework. There are advantages and disadvantages to each approach, of course! In that spirit, Frappe’s CMS tools and API give a lot of flexibility to build something elaborate, but the offerings out of the box are very useful for some but relatively basic.

In v13 e-commerce is getting reworked you can see the progress here in this patch. May be you can suggest the features you are looking forward to.

1 Like

Thank you this great discussion. Enjoying discussion with people who have a so interesting experience and makes me rethink some points of my own.

both approaches have not been endorsed by Tryton community to be included in core project.
Nevertheless, a company specialized in synchronization and built an advanced plateforme and a business.

The funny thing is that I thought the opposite :wink: so probably things are not as different as they look.

Tryton is made of a server called Trytond, and basic clients which are called Tryton, Sao, Proteus, Chronos for the officials ones. Trytond is a business object engine on top of database (postgresql, postgis, sqlite) via python-sql. Trytond core exposes an ORM to functionnal modules and to external applications via dedicated APIs. (Clients are external applications)

From my first understanding, Frappe makes no separation between the business logic and the GUI, I mean it seems you cannot use one without the other. Am I correct ? or would it make sens to use Frappe without its web interface ?

The default key and index is actually the name field, a string varchar(140). You cannot get rid of this name column, or change the datatype. Every DocType has it, and it’s the most-common JOIN between tables throughout the system.

You can store a hash in the name column (#0123456789). But it’s just a series of 10 Unicode string characters.

Agree 100%

Actually, the business logic is (mostly) stored server-side (Python code). The GUI JavaScript code is supposed to be limited to making navigation easier, drop-down boxes, etc.

Depending on who wrote the actual code, there can be exceptions. But I would say 98%+ of the business logic is independent of the GUI.

Probably would not make much sense…except there just aren’t many competitive options. I cannot think of any existing headless, open-source ERP systems.

So if that’s what you needed, Frappe would certainly work. You lose a lot of what makes it fun and interesting, though.

Understood and good to know.

I wasn’t thinking about headless, but more about alternative GUI. I brought this in this discussion because it helps me to understand how Frappe works. For this discussion, comparing the two architectures, it illustrates how Tryton works.

<off_topic> I got requirements for solutions for disabled people and people who don’t know how to read or write and I also promote a project which actually requires a headless ERP server :wink: so I may be influenced in the questions I ask about Frappe, always wondering “is it a potential candidate for this or that ?”.</off_topic>

I “believe” people have successfully made alternative GUIs. There was definitely several discussions about that a few years ago. Occasionally someone mentions this. But I don’t have any specific information or links to share.

Ha ha, shows what I know!

I was basing that assessment in part on what I understood (perhaps mistakenly) the relationship between Tryton and projects like GNUHealth to be. On this side of the fence, it’s important to note that ERPNext is “just an app” on the Frappe framework. That statement glosses over a lot of history, of course, but structurally it’s true. The business logic of “built-in” doctypes like Sales Invoices or BoMs has no special status above your own defined doctypes, and Frappe does a great job of abstracting away from the needs of particular record types. This is where Frappe/ERPNext really shines in my opinion.

The flip side to this, I think, is that compared to something like QuickBooks all of the document workflows end up looking the same. There is a lot of space for much more tailored, workflow-specific user interfaces, and Frappe makes that possible but there’s a lot of work to do.

Like @brian_pond said, the separation is actually quite clean. One could absolutely create a whole new user interface, including offline/desktop applications. There’s a new Flitter-based app for mobile, for example, which I believe is broadly independent of the web GUI.

More practically for those of us not looking to recreate everything, there’s a lot potential in building new UIs for specific workflows. At my org, we’ve been experimenting a bit with highly customized mobile apps, specifically for HR. The idea is that the HR manager will always use the full ERPNext web UI to oversee a diverse range of functions, but that employees will use a more tailored mobile app to do a few specific things like request leave, file expenses, etc.

I’d be very curious to know how Tryton approaches this kind of thing. Thanks for the interesting discussion!

Indeed, and thank you for clarifying. A new doctype can use any string for the name key, and on my currently installed version at least it defaults to 10 hexidecimal characters if nothing is explicitly defined. You are correct, though, that it always gets stored as varchar on the database side.

Thank you all for these explanations. I better perceive ERPNext now.
I see both communities aim the same targets on many points and are creative on their respective infrastructure.
I acknowledge also that both share the same openness and value free/libre software spirit.

I have seen several solutions

  • Outside Tryton standard, the Tryton client fork when there is a need which cannot be part of the official project
  • Supported by Tryton project, Flask applications embed Trytond code directly (import)
  • Part of Tryton standard, Chronos is an example of browser application (FireFox and Chrome). When you manage projects, users fill timesheets with Chronos directly from the browser without logins to the ERP. Every browser application accesses its own restricted API.
  • Proteus the CLI client is not used by end-users.