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

ERPNext
, ,
11

I appreciate that the custom frontends might not be for everyone. I don’t personally have much use for them either. But, they’re just another feature that can be used or not. The more mature and more familiar form-based interface is still very much alive and under active development.

I think where we see things differently is here:

I just don’t think that’s true.

I don’t know much about the new CRM app, but I believe Rushabh has said that it will be integrated with ERPNext’s sales cycle. It’s easy to create those hooks, so they’d be crazy not to! Contacts/phone numbers/emails have always been part of the Frappe core, so nothing changes there. Meanwhile, Frappe’s most mature separate app — HRMS — is fully integrated with ERPNext’s accounting, and so are many other now-separate apps: Lending, Education, Webshop, etc.

If the last few years are any guide, I suspect that’s the pattern we’ll continue to see: Frappe will remain a primary interface and data architecture, while ERPNext will become a new second-level “core”, focused on accounting and inventory. A new doctype in a separate app has no less access to ERPNext data than ERPNext itself does, and the maintainers have shown that they’re very happy to share data across app lines.

12

@peterg Yes, I think you’re correct, HRMS requires ERPNext to be installed, so it’s pretty tightly integrated and uses much of the same database. I would consider HRMS to be part of the ERP.

But the newer standalone modules, like CRM and Helpdesk, don’t require ERPNext. It would be nice if the UI of standard Frappe–and therefore ERPNext–eventually converges with the UI of the standalone apps, so everything is consistent and customizable in the same way. Likewise with the databases, but my understanding is that except for a few core Frappe doctypes that you mentioned (like contact & email/phone doctypes), the data is not currently shared.

13

To illustrate my concern, this is a fairly recent post from another user of this forum:

Last time I looked at the Helpdesk product, it had the same issue, unique and no integration with customers in core ERPNext. Made it useless to me

Besides the lack of integration, I also worry that concurrent development of standalone products will pull resources away from enhancing the core Frappe framework and ERPNext products.

Of course Frappe is a private company, and can choose to put their resources wherever they want :slight_smile:

1 Like
14

For example, there’s a 100% desktop offline-only accounting app being developed independently of Frappe/ERPNext. This app has no connectivity to the database or APIs. Very nice user interface but no integration with other apps…

15

I would not be surprised if this were the case. It’s certainly crossed my mind these past few years, and the minds of others.

Still, I have zero hard evidence to support this. I have no contacts at all at Frappe Technologies. I expect they’ll do whatever is in their own best, self interests. Just like anyone else.

Luckily, it’s all open source. So even if Frappe Technologies wins the lottery, decides to go colonize Mars, and never touches ERPNext again? :rocket: No worries. Others can carry on where Frappe left off, if they choose to.

4 Likes
16

An important question about the GPL → AGPL transition is not being addressed by Frappe: What happens if one wants to mix AGPL and internal apps in a single site?

It is unclear whether the viral aspect of AGPL requires the release of the source code of the internal apps in these cases.

Check this topic for more details:

17

In my opinion, an AGPL application such as CRM would not override the GPL license of ERPNext, or another GPL licensed app on that same server, because the applications operate independently.

If instead you developed a Frappe application to expand the capabilities of the CRM app, that might be a different story.

18

As explained in the other topic, the usual boundary for an xGPL license is the process boundary. This is why in the Java world there is the “ClassPath Exception” together with the xGPL licenses which was created specifically to get around this problem.

19

Exactly! :slight_smile: Frappe is releasing apps that can operate independently of ERPNext…except when they’re releasing apps that are deeply integrated with ERPNext. That’s how it’s always been.

I get that you don’t like the CRM or Helpdesk apps, but I’m less clear what previously-existing data integrations feel missing for you now. Rushabh has already said that the CRM app will feed into ERPNext’s quote->invoice flow. I may be misunderstanding, but that’s pretty much exactly how the currently monolith CRM module works now.

More explicit encapsulation will help to solve many of the problems that people have been complaining about for years, but because of how Frappe’s architecture works that imposes no constraint whatsoever on cross-talk. frappe.get_list('My Doc') works the same both between and within apps. It’s all the same data pool, all still accessible from the same unified UX.

20

Frappe Books was started six years ago, if I’m not mistaken. As a side-project, it seems to have gotten relatively little attention in recent years. That’s what I’m trying to say here: this isn’t a big pivot. Frappe has always had multiple products, operating in the same conceptual space, with varying degrees of cross integration.

1 Like
22

I love the move separating the one ring to rule em all into (7?) context specific apps - the OpenERP approach nearly always ends up a big ball of mud. The move from GPL to AGPL is important and I fully support that as well.

Often communications between well defined bounded contexts is minimal, but does anyone have experience integrating the separate apps? Perhaps Frappe HR accessing data from projects for non-salaried payroll? Or Frappe CRM accessing existing customer data and accounts?

23

I tend to agree on the lack of integration between ERPNext, CRM, Desk, etc. This is mainly due to the central entity of concern is the Customer / User / Contact / Organisation, with each app wanting to manage their own data set. it is nothing short of frustrating for all the mentioned apps to have their own repository of these entities. Surely something such as this should form part of the Framework rather than an app. Each app can certainly introduce custom fields, but surely these entities and their core fields should be part of the Framework which can then be used in any app wishing to utilize these entities.

2 Likes
24

@EugeneP
It’s a bit of a pain, but also offers incredible flexibility. Companies may NOT always have complete integration between each module depending on the case.

With linking and other tools, I can’t imagine why there would be issues. Customize the doctype, change it to link to erpnext customer. Done.

The way you suggest would limit ERPnext’s functionality due to how the data interacts now. Don’t get me wrong, that COULD be a good thing as it takes near a CS degree to be decent with Erpnext.

But then there’s always dollibarr, or odoo, or other erps that intentionally make the workflow simpler

25

@Jake

I completely disagree with the your premise.

The mere fact that Email configuration is abstracted into a module of it’s own within the Framework rather than re-configured multiple times in each app wishing to make use of Email, is indicative of the need to manage core entities separate from any app. Just imagine the uproar when someone comments by saying “Customize the doctype, change it to link to erpnext email. Done” for every app having their own Email configuration / tables.

Furthermore, the Framework does have a Contacts module, however the new CRM app does not utilise the entities within this module as you suggest, by simply linking them. In addition to these entities, it actually introduced new entities in conflict with what is in the Framework. It is a nightmare to figure out which entity is used. But most annoyingly, you end up with multiple versions of the truth: a single contact having differing contact detail in each app! Surely, custom columns/fields added to a central entity is a better way of accommodating each app’s unique data, if all that unique after all.

2 Likes
26

I empathize with the frustration, given the pile of various non-integrated apps. Absolutely a huge headache to maintain a “single source of truth”, and keep everything straight.

That being said: I understand and (mostly) agree with how Frappe Framework was designed. It’s sole purpose is to build a web app. Any web app. No matter how big or small. Regardless if that app has anything to do with business, ERP, CRM, etc.

I might want to build a web app that just displays the current weather. Or the position of the International Space Station. Or that plays Tetris. None of which have anything to do with ERP topics.

So I feel the Framework should not have Customers, Suppliers, CRM, Accounting, HR, or any of those business-specific documents.

The fact it includes things like Email, Contacts, User Authentication? Well, that’s part of its “batteries included” philosophy. We’re certainly free to debate what should, and shouldn’t be considered out-of-the-box. But personally, I’m (mostly) in agreement with what the maintainers have done.

A few days ago, I was explaining to a friend my “take” on the fundamental difference between ERPNext and Odoo:

  • With ERPNext, the focus begins on the framework, developer, and customization. The actual ERP application appears to be a secondary concern (albeit the app that made Frappe Framework popular in the first place)
  • Odoo is an ERP first and foremost. That’s the primary focus, and the company behaves like a traditional ERP provider. The open-core web framework and customization? A secondary benefit.

My customers tend to use only small portions of ERPNext. So I’m happy to see things become less-monolith. And more “opt-in when you need XYZ feature.”

But certainly everyone’s needs and experiences are different. I get where you’re coming from, Eugene.

as it takes near a CS degree to be decent with Erpnext.

lol @Jake . :100: :+1:

4 Likes
27

Sounds like you should go onto github and voice these concerns. Or message @shariquerik and inquire as to the reasoning behind those design decisions.

I don’t use the CRM app and just use ErpNext for this as my company does not need to utilize it to its full potential.

However, if the CRM app acts as you say, and does not support linking/adding custom fields back onto the erpnext customer doctype, or contacts doctype in frappe, then that does feel like an oversight. Erpnext is the most used app on frappe, period.
While nothing is truly trivial in software development, dare I say it would be “easy” to have a setting(or install script) in the CRM app that can be “checked” and use ERPnext/Frappe doctypes as single-source truth through linking.

It’s important to note some solutions/companies might utilize frappe and never need an overarching “customer” doctype so I disagree with your suggested approach, but I do believe full support of erpnext should be the priority of any app publicly supported and maintained by frappe.

28

Hello @brian_pond

I completely agree. Breaking the monolith up was the right decision. Retaining things such as Email, Contacts, Authentication, etc as “batteries included” in the core app, known as the Framework, was also absolutely correct. My concern is with the plethora of new apps not utilising these “batteries”, especially Contacts. There isn’t any other entity as important as Contacts to bring about integration amongst disparate apps. Just about any app will use some incarnation of a Contact and it’s Relationships with other Contacts and the Organisation / App it serves. Whether it is a user, stakeholder, guest, customer, etc. Why even have Contacts in the Framework in the first place then?

By “allowing” each app to create it’s own repository of these entities, we are not only actively encouraging un-integrated apps we’re actually distancing ourselves from the “batteries included” philosophy. Imagine the mess going forward with each app having it’s own Contacts, you may just as well go out into the FOSS world and select best of breed apps and face the same integration problems, bar for the fact that the UX is still somewhat consistent.

1 Like
29

On a similar line, I wish Gameplan used the “Task” doctype from Frappe core rather than it’s own custom doc. It looks like a super cool app, but if it doesn’t interface with my larger frappe/erpnext environment I don’t really see a use-case at my company. As much as I like Gameplan, it’s always going to be tough for smaller developers to go up against Jira and Slack.

It’s a tricky line. On the whole, I am very excited to see the shift towards separate apps, and it’s really impressive to see how much quality can be built for a (relatively) small amount of developer time on a Frappe+Vue stack. It’s clear that experimentation with differentiated workflows is where Frappe Inc is putting it’s resources right now. I’m a huge fan of that direction.

Rushabh has already said that more points of integration will be coming for CRM to link into ERPNext’s sales cycle. I’m very surprised to hear that CRM uses a separate contacts doctype, though, and I can’t personally explain or justify that choice. Helpdesk, for example, uses the core Contact doctype.

1 Like
30

In this case would be nice to know how to export the old “integrated” contacts and import it back in to the new separate CMR in an easy no hassle way,
if somebody is a plain user.

1 Like
31

If you want to start a new thread to discuss import and syncing, I’d be happy to discuss there. Feel free to tag me.

1 Like