Our goal is make ERPNext inclusive of all domains (monolith). The advantage is that the new user will find it very easy to setup any domain and it will not lead to fragmentation (multiple service providers doing the same thing).
As we go ahead, we plan to aggressively merge other domains in ERPNext too.
Looks great, is having a module in ERPNext some bigger advantage than being integrated?
I mean standalone app working along with ERPNext can have exactly the same functionality as an integrated module?
Cheers,
Can not 100% judge but believe that it is a great idea, and probably unique…
See classroom, teachers allocation as well as accounts in one environment…
great
robert
Overall it is a good idea. Perhaps it would lead to a set of Setup Domains (Use Case Profile Settings) where you would choose your domain during ERPN setup. Something like…
To get you started we have developed a set of setup templates to organize ERP Next, provide suggested chart of accounts, and install common apps for your type of business. You can always customize it further to suit your specific needs. Choose the best fit to get started.
“I will use ERP Next to manage a…”
[x] Include sample data
[x] Include suggested Chart of Accounts for [PICK YOUR COUNTRY]
I disagree with this direction. Schools should be separate from ERPNext and a user should decide whether they want it installed.
Separation of concerns takes precedence.
Saying that it makes it easier for a user is not quite relevant because if I’m a shop owner, services provider, manufacturer, etc, I have no interest in Schools. The only people who will have an interest in schools will be Schools.
I think we would all be better off if we made searching for and installing apps as easy as installing a wordpress plugin (and i realize that a lot of progress has been made in this area so far).
Or maybe, in the domain setup, the schools module is downloaded and installed in the background.
This is a great way to integrate all modules in to the same application. Just like any other ERP application all modules are part of the same application. It’s then the users decision whether to use it or not. Makes installs easier, as it would be the same install for the software itself then you’d use what you need.
From managing the software, changes, updates and patches, all will be applied to one place.
Thumbs up from me…
I also think, that it is not a good idea to put the app Schools into the kernel application.
As you know, every line of code increases complexity and possible errors.
A better idea would be to enhance the app interface. Eg a sub classing and a proper overriding / overloading of controllers and methods would be a nice thing. The hooks is a good approach, but real subclassing / overloading / overriding would be sometimes better.
With a mighty app interface there is no reason to put Schools into the kernel.
All big player in the ERP world are using a modular approach for creating vertical solutions.
In short terms…
Horizontal solutions must be part of the kernel.
Vertical solutions must be modularized in apps.
@felix if you select say Manufacturing, then all the roles related to schools will be hidden. So you will not even realize that app exists
@Idat-Consulting This is the classic Linux vs FreeBSD debate. I think a monolith is great because all domains will get equal love. What tends to happen with separate apps is that they tend to get neglected.
Also discoverability is also solved.
Additionally, this will motivate the community to start contributing their own domains, or theirs might be over-written by another one!
@rmehta I think this could be a good thing for the system as a whole. It could spark a lot of more collaboration too. Like this extension once it is done i would like to see it in the tools section. GitHub - vishdha/Meeting: Meeting Application using Frappe Framework. From what I understand is the codebase will remain modular?
