Hi.
Just started to test ERPNext, HR and CRM.
I am a bit puzzled as to why the Territory List of ERPNext is seemingly a different entity than the CRM Territory List.
Questions:
A) Is this by design?
B) Is there a way to sync them so that only one needs to be maintained?
Thx.
The frappe CRM app is different from the CRM that comes bundled in ERPNext. Site/crm is the frappe CRM and site/app/crm is the erpnext crm which is the legacy platform, which may or may not continue to exist.
The frappe CRM is relatively new and that explains no reports, funnel charts, sales personnel efficiency report, or fields like territory, employees count, industry, etc.
I am confused about this strategy from Frappe.
It makes no sense to have 2 separate products when you want a unified environment where information is not duplicated (nor maintenance efforts).
Do you know if Frappe has published what’s her roadmap?
We just started a cloud subscription and this is making me want to go cancel it right away.
Yes, custom fields are possible… yet not importing custom fields (the interface says it clearly).
That’s a huge friction to migrate platforms when you have a lot of custom fields. You’d have to migrate them one by one.
Hi, I’m not an official maintainer, but I come into that community just after genesis!
One thing I can say is:
Yes, you are fully right, it doesn’t make sense from the perspective of an unified platform!
But, let’s take from another perspective, Frappe Team, have invested a lot in what they call Frappe UI, that is the promise to revamp completely the legacy UI from JavaScript into Vue, but how do such project without make everything else a crap?
Building small products that solves common problems that need to be addressed on the main projects (Frappe Framework and ERPNext)
That’s why we have Frappe CRM, it have been developed as part of an strategy to UI/UX modernization and enhanced devexp!
Also, as part of an ecosystem, that the major idea is break down the monolithic approach that is there since the beginning of times!
That’s why now we have Frappe CRM, HRMS, Helpdesk, Builder, and many other good things that will come!
I get the advantage (& need) to modernize a stack.
What I don’t understand is the disaggregation of services when they are precisely supposed to be a unified user experience.
Looks to me that Frappe is trying to split modules so they can be sold separately, creating more confusion in the process. Updating a UX/UI is not a reason for this.
Is there a roadmap somewhere that I can check?
Thx.
No, there are no publicly available roadmaps for Frappe or ERPNext.
That’s a real pity. At this stage I have to put on hold our plans for ERPNext, then.
Thanks for the quick follow ups. Nice community.
I would say, it would have been much wiser to use the existing doctypes like leads, opportunity and just use feature ui as a frontend. A whole new app with new doctype doesn’t make sense to me too. Also, we have historical data of over 50k leads and almost 10k opportunities. There were so many reports and customizations that we have done using scripts and code that will all have to be moved. This approach of designing a new app from scratch wasn’t very well thought.
We are working on rewiring the frappe crm to use the existing doctypes from erpnext. Does anyone here want to collaborate or fund?
They never have a roadmap, although you can deduce certain movements in github and the intentions with the projects (a year ago there was not even that), but then you are baffled by the priorities. A clear example is how long it took to connect the CRM to ERPNext, a whim the way they treated the priorities.
The reason is clear, there is a new opportunity to create apps that besides being able to interchange without ERPNext, allow to have a personalized UX and less complexity oriented for an end user.
What is not clear is the way things are communicated (the confusion about CRM is incredible in discuss) and the low priority of integrating it into ERPNext (it’s practically a dead start).
I would say, it would have been much wiser to use the existing doctypes like leads, opportunity and just use feature ui as a frontend. A whole new app with new doctype doesn’t make sense to me too. Also, we have historical data of over 50k leads and almost 10k opportunities. There were so many reports and customizations that we have done using scripts and code that will all have to be moved. This approach of designing a new app from scratch wasn’t very well thought.
Here I do not entirely agree. It is precisely because otherwise we can never move forward. The issue of customizations and scripts has always been a double-edged sword, because it limits your progress.
In any case, I would believe that in cases like yours is that the old version is maintained, until at some point make the final transfer (whoever likes it). Be sure that one of the issues of the repo creator, is a migrator at some point.
And on the other hand we have solutions like this one:
Where they can’t wait for v17(which would be the logical thing to do) to have a full integration.