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.
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.
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 
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 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