This is a good idea in general, but regular business stakeholder “users” will likely be taken advantage of. There will be a big difference in final pricing if I were to put a (fixed price) project on Upwork Vs. if the companies owner were to do the same. I guess if pricing isn’t a concern though (i.e. you need your custom feature/function bad enough) then it wouldn’t matter.
Still, if I were to pay for some custom module work for our instance of ERPNext, I’d definitely try to make it generic enough to share with the project team, or at very least share on github.
There is no way to determine the whimsical choices of the developer team that reviews the PRs. So even if it is well documented, tested, and presented in the format they prefer, there is no promise it can get into the system.
If this were a system structured around an unchanging framework, then one could create apps to fill in the gaps. However, core modules do not always lend themselves well to interacting with other apps in the framework. And even then, there is the possibility the framework or the core module changes to negate your effort.
I’d be curious to know about what breaking changes you’ve encountered. I’ve had relatively little difficulty across versions with my org’s own customizations, which are relatively broad. Of course, everyone’s experience on this will be different.
That said, I’d love to see Frappe continue to mature in this regard as a platform, particularly on the question of how to produce more stable abstractions and interfaces. This would be a great topic for a community user group to start thinking through.
Development is always going to be expensive. There’s just no way around that. People who can’t afford those costs – whether in time or money – are always going to have less control than those who can. I don’t think that will ever go away, but Frappe has done more to minimize those costs than any other framework I’ve worked with. That’s what excites me about this platform and its democratizing power.
As raised in many issues partially dating back several years, a proper implementation of process manufacturing would be amazing! This issue has been raised repeatedly over many years and is needed by several users
According to wikipedia, process manufacturing is used in many different sectors including food, beverage, chemical, pharmaceutical, nutraceutical, cosmeceutical, textiles, consumer packaged goods, cannabis biotechnology industries, semiconductor fabrication, steel & aluminum, aircraft & spacecraft (and I believe this list isn’t exhaustive). To me it seems to be a fairly basic feature (in terms of what an ERP system should be able to handle) that should have been included in ERPnext already a few years ago.
If you search by “Breaking Change” in this forum, you will find many!
On the past I developed the Title Links resolution for an important problem in ERPNext and frappe
After a period making it mature, one commit on the UI of the framework, completely and silently deprecated the JQuery widget that was being used to address the problem, using Awesomplete instead, what turned almost impossible at least to me maintain the app.
There’s other cases also, but or they are smaller or they dont resolve important features!
I feel that one area that ERPNext has to look into is an Engineering module A lot of companies do design and development of products. It requires a lot of feedback from various business activities and a lot of businesses need to track the development cycle of the product. Incorporating it in ERPNext will make the product cycle complete and also make it easier for companies to track the revision of the products.
Warehouse bin system is another feature which I would definitely like to have
QR code for the fields in printing and scanning them creating new documents or opening existing documents from QR code will also be nice
As a senior at user organization and past IT consultant (Siebel CRM/ SAP ERP) in early career,
ERPNext is without a doubt the most agile, modern enterprise application (framework).
Changes are easy to make, as source code is open. Cost is low. Oracle/SAP and IT Organizations would charge comparatively hefty fees for even smaller customizations.
For Other Biggie ERP/CRM/Enterprise apps also: Numerous Breaking changes and bugs introduced in every version upgrades. Customizations or hacks are not guaranteed for version upgrade fixes.
For Other Biggie ERP/CRM/Enterprise apps also: Customizations are developed on top of core. Core is not tinkered for customers individual requirement. This is logical too!
If customization stands a point that it is generic enough to represent a industry, is included in core not earlier than next version if decided so.
So I don’t think it is big deal for few breaking changes, afterall some of the customization was built as hack as you mention.
At the same time I find some members request very conflicting, at one end they say feature fatigue but at the other end they say new inclusions based on (specific) customer feedback
Even I want to see hundred changes in ERPNext, but that is my Wishlist for my organization. If implemented, that is my competitive advantage. If generic enough I will share and leave it to product owners.
See everyone of has devoted some part of our business with our stacks on ERPNext and Frappe’. But few have gone beyond and devoted major part of their professional life building a cool product. So would urge in favour of all of us, lets trust people who are completely committed to growth of ERPNext. As world has seen with Linux, I would like see with ERPNext.
Can this be tackled with testing?
After all if we add accepted functionality to the core and provide proper testing, these will reveal if another contribution breaks it and there should be some coordination to unwind this problem.
Of course for code maintained outside the core another solution is required. But since maintainability of external applications is important, I think there could be a board that informs about planned changes in advance. I remember to have read such a proposal before.
Good tests are extremely valuable, but I don’t think it could fix the issue here. Max was hooking into a widget deep under the hood, and when that internal implementation changed it stopped working. The change was intentional, and of course it’s not possible for the maintainers to consider every individual’s customization when improving code.
The longer term solution is abstraction. Frappe is extremely well conceptualized as an architecture, but especially on the UI/UX side there is still quite a bit of work to do defining APIs for different kinds of interactions. A lot can be accomplished with monkey patching, but that is always going to be vulnerable to breaking. Instead of overriding a private implementation detail, what we could really use is an abstraction layer for defining custom link field formatters.
I would love to see another “Production Plan” option but instead of being built for a discrete manufacturing process I would like another “Production Plan” for process manufacturing.
There is an App “Process Manufacturing” that does a very small part of what the current production plan can do.
Having a production plan that can still create work orders based off of quotes/sales orders as well as automatically create job cards, while still catering for Process Manufacturing, that would be fantastic.
Agree with the abstraction.
as mentioned by other comments, this could be a reasonable working target for v14.
No new features, but making ERPNext more robust and introducing abstraction layers to enable better collaboration and customization.
For the mobile app, on iOS, it would be great to be able to use the standard iOS document scanner to attach PDF scans to different Document Records (ex. Packing slip from supplier when receiving parts).