Query on the Purpose of Separate Apps vs. Frappe/ERPNext Integration

As I previously mentioned, the apps may technically share the same database, but don’t share all the same data (which you have acknowledged). And I never said Frappe instances don’t have the same UI. I said the standalone Frappe apps use the “Frappe UI” components (Vue 3/tailwind based), which ERPNext doesn’t, which means there is diversity in user experience and customization.

Sorry, I feel a bit like we’re running in circles, hopefully the above clarifies what I was trying to convey.

1 Like

Its for that reaseon, the client-rewrite is in progress. After a lot of processing, it could be a very good thing to separate two interfaces, one for the advanced system user (configurations, parameterisation, etc. and one for the end users/employees), but I don’t quite understand how it will affect essential documents such as invoicing, payments, etc.

Both the new client-rewrite and the convergence of the apps (the discussion of how they will link CRM, Helpdesk, etc.) is supposed to be revealed in October.

3 Likes

Hi all:

Many users can now use CRM easily because it’s a separated app. Fight against the whole “monster” ERPNext would be challenging, so I think is a good decision.

Maybe this new apps are a good “lab” too for FrappeUI and upcoming Frappe Desk client rewriting. Anyway, CRM creator and maintainer, have publicly talked about plans to “connect” CRM with ERPNext. Hope Helpdesk will take the same way.

Other new apps like Insights, Drive, etc … have total sense as separated apps, with proper ERPNext connection.

This is my humble POV.

3 Likes

The move toward a unified interface and more interactivity between modules sounds promising. Hopefully in October the overall product development strategy will become clearer.

If the eventual outcome is that the ERPNext monolith is broken into separate modules, some of which can operate independently, fine by me, as long as there is no duplication of data and the user experience is consistent across modules. There is no technological barrier to applications sharing tables when installed together, or operating independently if not. As I mentioned earlier, that would be more analogous to Odoo’s architecture, which IMHO has been largely responsible for that product’s success.

@avc I want to believe that they are not going to leave it up to each developer who maintains the app to decide how to connect it.

The deeper conversation about how to handle key documents that can converge (contacts, to give an example seen in the discussion) is what Frappe should be proposing. Today there are few apps in this situation (CRM, Helpdesk and not much else) but can you imagine if each one takes this decision separately where we will see Projects, Manufacturing, Credits, HRMS in the near future with this UI and maybe separate?

I have always found it difficult to understand the position of not being transparent in certain aspects towards the community(customers its a better term). You have to understand that the low adoption of CRM and Helpdesk (which already has its time) is that no one can be clear about the horizon (are they integrated? is there a more general position as the one I raise? etc), and no company can take big decisions with this uncertainty.

I know, it’s free software, take it or leave it, but I see this kind of thing as the saying of shooting yourself in the foot. I think this v16 is going to be key, and if this game changer is well organised, the future looks very promising for Frappe.

2 Likes

This is pretty much exactly how Frappe Inc works, though, at least as I understand it.

1 Like

I know, that’s why I want to believe that something that could involve the way everyone connects, could go beyond individual decisions.

I have a confession to make … I’m a (almost) new user. First time I knew Frappe and Frappe’s way to do things I got really scared: Aparently chaos, improvisation and many contradictions … Even I didn’t totally trust, as I thought that was not possible to run (more or less successfully) that way.

After this 3 years, just to say that I’ve never seen more transparency in any company. I think that Frappe Technologies don’t always know what to do. This is exactly I expect, because I don’t always know what to do either.

I love Frappe for what they do and how they do it. Maybe isn’t the canonical way to do business things, probably it will not reach many success on Linkedin :wink: and they are not going to become billionaires (I’m beginning to suspect they don’t want to … :joy: :joy:) But looking at all that they built until now … seems it works. Don’t you?

9 Likes

Up until the last couple years, the answer would be definitely! But I do worry now about fragmentation of the ecosystem and neglect of the flagship ERPNext product.

For that reason, I’m taking a closer look at Odoo for customers. Although they’re not open source to the same degree as ERPNext and have a couple hundred million dollars of venture capital that’s going to need a return on investment sooner or later (i.e. prices will eventually start going up for their enterprise edition), they’ve remained exclusively focused on enhancing and expanding their core ERP offering.

1 Like

So basically you are afraid of many other people’s decisions.

There is no way to fix this.

Unless you want all these other people to submit to decisions of a leader endowed with forcing power. Consequence: Freedom destroyed.

The only solution is to grow up together and learn to love and to trust in order to work together for the common good and joy. That’s the unavoidable cost of the Real Freedom we are made for and, let’s be honest, also long for.

1 Like

This is what we discussed in our last internal team meeting.

The current state of affairs is:

  1. We have Framework Desk UI which is extremely feature rich but offers very little “composability” in terms of layouts / UI
  2. On the other end of the spectrum is “Frappe Builder” which is very composable but not feature rich from an application development framework POV.
  3. We have Frappe UI, which is a component design library that can connect the two - what we need is a new UI platform that will give you the richness of the Desk UI with the composability of the Builder.

The long view

The way software applications are built today is totally broken. You have to learn so much to build a simple app - client side, server side, infra, databases, CSS, auth, permissions, etc. Learning CSS is like learning byte code in the 90s.

What we realise people love about ERPNext is the customisability of the Framework. For us fixing these fundamental problems is very important. Framework is great, but can be so much more better looking at the current crop of low-code (toy like) tools. So we will try and take a stab at fixing the holy grail - “Let’s make it application development simpler” with a visual builder, schema designer, data manager, permissions manager all baked in with a “one click publish” platform.

Also we are not in a hurry. It may take us 10 more years to fix these problems, so be it.

What about ERPNext?

ERPNext continues to be a core focus - we have entered into a partnership with Resilient Tech @snv and @Smit_Vora who are better equipped to build out the ERP features. They are both trained accountants (unlike folks at Frappe) and proved themselves with the amazing India Compliance app. Along with this @nabinhait @rohit_w and @Ruthra from Frappe are committed to take ERPNext forward along with a bunch of new hires. This is also a big change in direction where we are working more closely than ever with the community to build out the product. We would love to work with more folks (making regular contributions is a great way to start) in the community and ideally the “most capable” person should be the one driving the project foward, whether that person is from Frappe or not.

New products

The new products are built without any legacy. We see each of them (Helpdesk, CRM, LMS, Website Builder, Insights BI, Drive, Wiki, Gameplan) as a different product category and they should be built to solve those problems. They are still very “young” and we hope that will soon be drivers of this community as much as ERPNext. Any connectivity to ERPNext will be Phase II. Also there are no plans to remove the basic CRM, Support, Projects modules from ERPNext itself.

From Frappe’s POV, we will try and solve as many problems as we can while building a sustainable + 100% FOSS product. The enhanced focus is probably more on quality than anything else at this point.

In the short run, some things may go fast / slow. But the overall vision is to fix deeper problems in the app development space, while building out ERP and a bunch of other products.

24 Likes

@rmehta Thank you for this summary. For the short term do you plan to finish the migration of the Desk UI to the Frappe UI / Vue based solution (client-rewrite branch)?

4 Likes

Moving along your own pace fixing things that people feel needs to be fixed, creating things that people feel needs to be created. It’s not a one man show, never was. That is what it means to be FOSS.

OEM aside, anyone with the proper knowledge can easily contribute features to be added into the framework’s codebase, or even host their custom features as separate apps. This truly is a magnificent product aimed towards promoting FOSS development.

As rightly said, people can focus on the Ideas and quickly implementing the features (which might be groundbreaking or mundane) without having to spend years in development tutorials to learn all the necessary tech stacks to do it. (Mastery is a whole different story though…)

Looking forward to contributing in the years of slow but sure transformation of this framework irrespective of whichever direction the community decides to move towards.

1 Like

There is a desk rewrite in the works - but we want to completely re-imagine the app development experience for that. It will be a parallel implementation than a rewrite.

There will be continuous improvements in desk UI though with the goal of making it cleaner and simpler and more in tune with the present day sensibilities.

4 Likes

Thanks this explanation is very useful. I finally (after lots and lots of searching) understand that ERPNext has basic modules for CRM, Support etc and that the stand-alone CRM, Support etc apps are more features rich, but not yet integrated with ERPNext.

It is a mystery to me as a potential user why this dev approach has been chosen though. I have to choose soon between Odoo and ERPNext. I like ERPNext because it is FOSS instead of opencore + because of its reputation for ease of use and customizability. BUT it is not great to know that the CRM and Support modules we will be using are not as good as the newer Frappe apps for this (and thus might also receive less development going forward). It would have been much preferrable imo if the development effort to create the CRM and Support apps had been used to improve the CRM and Support modules of ERPNext. Ideally, a modular approach would be adopted like for Odoo, where users can decide themselves which modules to include to make the install not unnessicarily large.

2 Likes

Can I make a humble suggestion, which is to actually set up an instance and see for yourself if frappe/erpnext suits your needs? I think there are about 80 different understandings of what “integrated” means floating around in this thread, many of which have no bearing on how Frappe/ERPNext actually works.

A bit of hands on time will go a long way towards understanding if Frappe will suit your needs, in a way that reading these discussions likely won’t.

5 Likes

I love the vision @rmehta. In my opinion, Frappe could be vaulted significantly towards your stated goals, even in its current state, with two additions:

  1. A visual automation tool (think n8n inside Frappe).
  2. Formula fields supporting excel-style syntax for calculations on both forms and lists.

Salesforce provides a fantastic proof of concept for both.

I say this from real-life experience developing apps based on Frappe, where most of the scripting I do on a regular basis would be almost completely resolved if these two features were available.

And while we’re on the subject… formula fields provide an easy illustration of where I hope the platform goes with metadata-based development. A huge portion of the scripting that currently exists in ERPNext doctype-specific scripts (python and javascript) could be consolidated into metadata if the model were extended further. Dynamic visibility/mandatory field conditions, rule validity conditions, child/parent calculations, document states and their definitions, could all be defined in the metadata instead of doctype-specific scripting. Not only could this accelerate development, it could also pave the way to a variety of frontend interfaces on the underlying model (web, mobile/flutter, desktop, TUI, etc) without platform-specific re-implementations of each Frappe app.

9 Likes

[quote=“batonac, post:63, topic:121404”]
A visual automation tool (think n8n inside Frappe).
We are using N8N to connect Frappe with other apps, it will be great to understand your perception of incorporating n8n type UI or N8N sitting inside frappe; what we can achieve with ease will be helpful for the communication across

1 Like

Well there’s nothing quite like a native tool. I expect that third-party solutions like n8n will continue to excel for integration automations between systems, but a frappe-native tool that’s built around the Frappe document actions and dataset would be swell. Again Salesforce Flows are even closer to what I’d hope for.

But what am I harping about here for? This has already been extensively discussed in the forum and has a feature request tracker.

1 Like

Re this issue in general and @rmehta 's post above. One of ERP’s key strenghts is the sheer number of business objects it has. And the relationhsip between them

One option, could be to de-couple the UI from the logic. The back end then becomes business objects communicating with a databse and the front end would be “just another UI” - calling these business objects. Frappe’s UI already allows us to make data calls.

This would mean that the UI, however it’s done technically would be making calls like (psuedo code):

const salesOrder = new SalesOrder(customer)
try {
  salesOrder.create()
} catch (CustomerCreditLimitExceededError){
  // customer doesn't have enough credit.... handle this case

... and so on ....

I think this type of approach has been tried a few times by various vendors, over the years, but maybe its time has come???

1 Like