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

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?

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.

1 Like

@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

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

1 Like

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:

1 Like

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.

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

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.

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

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