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.
@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
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.
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:
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 . 
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.
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.
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.
Hi all,
potential new user here, we are considering ERPNext / Frappe for our ERP needs.
I have been looking a little bit into this, but it is still unclear to me. There appears to be ERPNext, and then there are others apps like the HRMS module that requires ERPNext as a foundation. But then other modules appear to be completely separate (and not integrated, or sometimes yes?).
So here my question: Does Frappe have an overview somewhere of:
A) what is included in ERPNext vs in separate modules (eg if separate modules do something ‘more’ than the comparitive module in ERPNext)
B) what kind of “addon modules” there to ERPNext like HRMS and if these are included in the 50 eu per month subscription for ERPNext
C) how we could start using things that are in separate modules when we are using ERPNExt + if those separate modules would be connected to ERPNext somehow?
Rik
Hi Rik,
In Frappe, all applications store their data as “Documents”, and all Documents are editable and accessible from Frappe’s primary interface, the “Desk”.
Apps are just bundles of Document Types, and all DocTypes have access to all other DocTypes installed on the same site. Any App can use data defined by another app just as it would use its own. The Salary Slip DocType (from HRMS), for example, can create accounting entries using the Journal Entry DocType (from ERPNext). To make sure this is always possible, HRMS lists ERPNext as a dependency. They are integrated in this regard. When designing HRMS business logic, the development team relied the existence of ERPNext’s accounting module and fed data into it appropriately.
Recently, the core Frappe Inc team has been working on some new apps that have lovely new dedicated UI/UX designs. You can still access everything via Desk, just as you always could, but additionally they come bundled with bespoke single-page apps with a workflow-specific layout. These apps still live in the Desk (erp.yoursite.com/desk), but they also have a separate url for the specialized interface (erp.yoursite.com/gameplan, or erp.yoursite.com/crm).
When people say the new apps aren’t integrated, they’re saying they don’t feed data into other apps as part of predefined workflows. The data all lives together, however. You could still design a report that draws data from the CRM app and ERPNext, and nothing in that regard has changed.
I’m not aware of any simple chart that shows connections between different apps. Formal dependencies are defined in each app’s hooks.py file, but identifying specific connections would require looking at functionality.
As far as subscriptions go, all Frappe/ERPNext applications are free, open source software. The 50 per month is a reference to hosting and support on Frappe Cloud? I believe you can install any Frappe application you’d like on Frappe Cloud without any additional cost.
thanks @peterg this helps a lot. Yes I meant the hosting on Frappe Cloud – we try to support the developers of FOSS when we can by taking a subscription with them.
A small followup question: how do the apps related to ERPNext when there is overlapping functionality. For example, I noticed there is a Helpdesk Frappe app. But Helpdesk is also a part of ERPNext. Are these two the same? Or are they different? Should we consider the additional app or will the Helpdesk part of ERPNext be equally good?
thanks
There’s no Helpdesk module in ERPNext. There used to be a Support module that had some similar functionality a few versions ago, but that has been spun off and separated to make the Helpdesk app. If you want helpdesk/ticketing functionality, you would need to install the Helpdesk app (or design your own).
OK thanks it is starting to become clear!