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!
Thank you for the explanation; it makes a lot of sense. However, I have a question regarding the desktop app called “Frappe Books.” If the other apps are being developed independently of ERPNext, does that mean ERPNext is being decoupled and will no longer be considered an ERP, monolith, or single source of truth?
Alternatively, should ERPNext be renamed “Accounting App” and have its interface similar to CRM, GamePlan, etc.? In this scenario, all app document types would be accessible through the Frappe admin interface, known as Desk.
When you create a Frappe site, all of your data is in a single place. All of Frappe’s tools, APIs, and core interfaces access that data in exactly the same way. This is true regardless of how many apps you use. From the Desk (Frappe’s primary user interface), all app data is equivalent. A doctype can talk to another doctype in a different app just as easily as it can talk to its own.
ERPNext is far more than just accounting. I can’t for the life of me imagine that it will ever be feasible to build specialized interfaces for everything it does. Desk is here to stay.
For that reason, I don’t think it’s accurate to call Desk an “admin” interface. Apps like Gameplan, CRM, and Helpdesk provide a simplified interface to common workflows for users who need very limited functionality. Those users may never access the Desk. But, Desk is still how a typical business will interact with the vast bulk of its data, including everything in ERPNext.
I think Frappe Books is causing some confusion here. Frappe Books is a separate, standalone product. It is not a Frappe app in the way that CRM, Gameplan, HRMS, or ERPNext are. It is a standalone accounting program developed several years ago for users who don’t need a full ERP. Frappe Books is not relevant to discussions of ERPNext’s monolith/non-monolith design philosophy.
I think one major point that is being missed in this discussion is: what is the future of core ERPNext? The more features that can moved out of it into standalone apps, the less robust the monolithic ERPNext application becomes, and the more Frappe (company) resources get pulled away from ERPNext’s ongoing development.
It doesn’t really matter if they can co-exist within the same Frappe (framework) environment, if their data isn’t 100% shared, their UIs are different, and customization approaches vary, then they’re not really an integrated ERP. I know there’s talk of additional data exchange down the road, but to me that approach seems backwards.
Certainly, one can argue whether Odoo is really an open source ERP, but at least they got their architecture right: a fully modular approach where all apps can–and do–share the same database. The UI is also consistent, with the same customization options across all Odoo apps. Frappe (the company) seems to be moving the opposite direction, for better or worse.
I suspect you know everything I’m about to say below, @DCRob, but I think you’re being a bit fast-and-loose with terminology here. That can be very misleading to people who don’t understand how Frappe/ERPNext works behind the scenes.
All apps in a Frappe instance use the same database. Full stop. If you create a new site and install CRM, Gameplan, ERPNext, and HRMS, there is only one database for all of them.
Frappe has a wonderful unified UI called Desk. It is the one UI to rule them all. It is robust, mature, and under very active development. The vast majority of things you can do in Frappe/ERPNext can be done only through the Desk. Recently, certain developers have been making specialized workflows tailored for particular workflows. These are opt-in. You can ignore them completely if they’re not useful to you. The Desk is no less powerful than it was before their release.
No grand shift in ERPNext’s functionality is taking place. Frappe Inc, the company behind the bulk of ERPNext’s development, has always been highly decentralized, with independent developers working on projects that interest them without much top-down control. That model will not suit everyone’s needs, but I’d argue it’s pretty beautiful to see in this day and age.
Actual issues raised here, as far as I can see, are just a few things:
I agree fully that this seems like an unfortunate design decision. Gameplan in particular loses most of its utility, in my opinion, by not using core Frappe’s ToDo doctype for tasks. A few scripts written in Desk would make syncing these relatively straightforward, but it shouldn’t be necessary to do that.
The only specific missing feature I’ve heard named here is CRM Opportunity → ERPNext Purchase Order. I agree that’s a useful feature, and something that Rushabh has said is coming. Adding it to your own site in the meantime would be a relatively simple customization that can be made directly from the Desk.
Yep. They don’t work for us. If you want them to add the features that you do value, there is a simple and established pathway for it. Or, you can add them yourself.
Regarding sharing the same database, although that may be technically correct with regards to which MariaDB instance is being used by apps installed on the same Frappe server, I would not say that the new standalone apps on ERPNext share all the same primary tables. As you mentioned, there is data duplication and lack of interoperability, which is the primary gap an ERP is designed to solve.
And screen customization methodology differs between the standalone apps and ERPNext. So I guess we disagree on a couple points.