If you were to abandon ERPNext, what would be the reason?

I worked on SAP for more than 20 years, dedicated my spare time on Frappe/ERPNext more than 5 years now. I tried my best to promote it locally in China, till now there is little progress made. I love Frappe/ERPNext as always, I regularly check (Learn) and answer questions(Contribute) I am interested in this forum.

9 Likes

I see things very differently, and I think that different perspective is a big part of why Frappe has been such a great fit for my organization. In my first post here, I said that nearly all bad experiences come from a misunderstanding of what ERPNext is (and isn’t). I stand by that, so at risk of being a bit self-indulgent I’ll share a bit of background that might help people decide if ERPNext is actually what they’re looking for.

(Long text ahead!)

I work at an academic cooperative. We are perpetually tight on cash but have a great network of very dedicated volunteers. A few of us manage an ERPNext instance on behalf of the organization, and it’s done amazing things to support our experiments with transparency and distributed decision making. (Incidentally, it’s been very cool seeing Rushabh’s blog posts about similar experiments at Frappe Inc. We didn’t know anything about the company behind ERPNext coming in, and I’d still say it was a great product if it had come from a more traditional company, but the philosophy certainly makes the project feel more kindred to our values.)

On needing to be an experienced, full-stack developer: I just don’t get this. I hear it said all the time, but it’s so contrary to my own experiences. I mean, I’m a college professor…in a very “soft” branch of the social sciences, no less. I did a bit of web design a million years ago in college (back when jQuery was cutting edge), and I have a decent grasp on core CS concepts from work I’ve done in data analysis (mostly in a very specialized programming language with no application to modern frameworks). Beyond that, I’m a total amateur. When I look at pull requests by people like revant_one or rmeyer, I barely understand what’s happening. The first python code I ever looked at was ERPNext’s. Even with that minimal foundation, I feel like I’m able to do pretty much anything I can imagine. Frappe has a great architecture of hooks and customizations accessible from the client-side, which makes meaningful development a very rapid process.

On being less mature than the “traditional” ERPs: I’m sure this is true. But, I think it’s important to understand the trade-offs. Another organization I work with has a very expensive SAP install. They ran into a show-stopper bug/limitation related to multicurrency invoicing, and getting it fixed ended up costing them about $35,000. At my organization, meanwhile, we wanted to add multi-currency support to the POS. I had it working in about 8 hours of my own (amateur) development time. If I had known what I was doing, it would have been half that.

I’ll echo @mcd.steven here to emphasize that Frappe has always been “framework first”, which sometimes comes at the expense of individual doctypes but makes custom development so much more accessible. We’ve probably had to do more customization/fixing with ERPNext than we would have needed to do with one of the “old-guard” ERPs, but with those old-guard systems the barriers to customization are much, much higher. That’s the structural trade-off, and as an organization we’re very happy with the balance.

On being difficult to install and deploy: Having watched this forum for several years, I have developed a strong opinion on this. I see zero reason why anyone, especially newcomers, should be installing ERPNext manually. In 99% of cases, docker or frappe.cloud is the correct answer.

On planning and relationships with the community: This I also feel strongly about. I understand why some people want a roadmap, complete with formal processes for incorporating feedback from diverse stakeholders. Frappe has a very different ethos. I find their approach dynamic and effective. That said, there are certainly arguments for other, more centralized styles of governance.

But, it’s a fine, fine line between “offering feedback” and “having other people do what I want”. Ideas are cheap; work is hard. I’ve never seen an open-source project at this scale where the maintainers are more actively engaged with the userbase. At my organization, we also use Moodle and Drupal a fair bit (though we’re shifting much of that over to Frappe now). Both of those projects have very strong planning processes, but getting a seat at the table means committing hundreds or thousands of hours a year in developer time.

That’s the blunt reality: I think there’s a profound misunderstanding on these forums of who “the ERPNext community” is. It certainly doesn’t include me or my organization, at least not more than superficially. It’s definitely not this forum. Open source belongs to the builders, and most of us are here to benefit from everything they choose to share. There’s nothing wrong with that. I don’t think that Frappe contributes much back to nginx, nodejs, mariadb, or any of the other open-source packages it depends on. The value those packages offer is beautifully public. Likewise here.

But, work belongs to the people who do it (or, at the very least, the people who pay for it to be done). I’m not aware of a single open-source project anywhere that works any other way. If we want to talk about how empowered or influential the community is, it’s a question we’d have to ask the very small number of people outside of Frappe Inc. who devote significant time to building.

16 Likes

it would have to be the e-commerce for me. no guest checkout and such.

1 Like

This is a really long and interesting thread. Thanks everyone for sharing the feedback. Some comments:

  • My key takeaway is that it seems people want better user experience (UX).
  • I don’t think there are any major bugs post v13 (we know this because we support more than a thousand installations) but some settings are clunky and things do break specially when people customize things the wrong way.
  • Migrations are always tricky and we cannot foresee every scenario specially while migrating old data, if you have non trivial data, its best you engage an expert.
  • Scalability is also something you have to manage. If you have high volume of transactions it is always better to have a staging table where you can dump your raw transactions and then post (daily) summary transactions in Core ERPNext. This will have to be scripted by experts because every scenario / data model is going to be unique.
  • UX is also something that is taking priority in the Frappe devs. Now we have stable code owners for most of the core modules (this wasn’t always the case) and they have to manage their support too. But this won’t be fixed overnight - expect at least a year or more for consumer class UX.
  • We would love to have feedback on bugs, UX etc, but I don’t think its fair to expect Frappe team or any contributor to deliver on some of your feedback. This kind of behavior (expectation of free labour) is not the right spirit in an open source community. Remember this is the “commons”. If you can’t help, at least don’t dump your frustration on people who are contributing!
25 Likes

I find this thread valuable too. While it’s always easy to find project’s PR hype, and (in case of open-source projects) its bugs, but usually it’s hard to find insightful comments from long-time users if you don’t know any in person.

I’m particularly grateful for constructive criticism coming from users with good reputation on the forum, like @peterg or @brian_pond. Their feedback is really something to think about, when deciding if we should commit to Frappe and/or ERPNext and if so, what can we expect from it.

I’ll probably come back to ask more detailed questions on Frappe
And probably answer some as well. :wink:

Thanks again.

5 Likes

Yes, it’s for $15,000/year. I don’t know how people don’t find it a lot. Comparing it to the general cost-of-service in my country and amount of work for my small company, it is too much.

They need to have different levels of support otherwise it is tough for small companies and retailers to switch to ERP Next. That is what the Founder’s dream is and I align with his sentiment. I understand the potential of organized data entry and its analysis which small organizations lack.

They need to make their support more approachable for new implementors and small businesses.

2 Likes

They do not provide MWS anymore, no matter hoe much you explain, no matter how much you beg… no, they only forward to SP-API, no matter what they say. tried many many times, with different amazon seller accounts. So Please you do something about it, maybe you register ERPNext there on amazon application center ha ?

1 Like

I know i have criticized hard, i am sorry about that, its just, i know there is great technology behind that. i am too far from being a coder, i am an end user, i am an amazon seller, in theory erpnext, when its ready for production, will add great, awesome value to market. it is free, its working very fast, it has good modules, good looking etc… i wish at least some of the modules could be useful to me ( without hiring a python expert ) like woocommerce sync, amazon sync…

I have noticed something, this is my general observation dont take it personally, indian based coders always demand and require too many form data, every simple screen is asking to fill a lot of fields, i know they have all purposes but thats not the way europeans use tools. for example do we really need tax template groups of groups or multiple cost centers finance books, things that contains each other ? while importing simple product data, there are so many fields erpext is asking for, cant there be an automation, pre- assumptions, pre settings etc ? there are a lot of filelds in products, sales order, sales invoice forms or project forms, that shouldnt be there but should be in SETTINGS section. i read you will focus on user interfaces user experiences, thats why i wrote, someone who is following erpnext since ver10, and i really appreciate all the good work. i am not a coder but i can understand how fast its working, i read things here how awesome is frappe. i will continue following erpnext, maybe support in future, i hope erpnext will be the next big thing after wordpress …
regards to all

I don’t think this is “an Indian thing”, I think this is an “ERP thing”. The systems are developed to support all functions in all businesses - so they build a model that can be used in most scenarios.

It’s pretty easy to hide any fields that are not required (as long as they aren’t mandatory). I would always start a company by hiding as many modules / fields as I can so they get used to it and then add things in as they get comfortable and familiar with the system.

You generally end up finding they want to use most if not all of the fields once they are comfortable - but in the early stages, it’s just overwhelming. That’s just ERP systems as whole, not just ERPNext.

If you’re not happy hiding a field, just moving them around to display what’s needed at the top can also be quite effective at improving the user experience.

2 Likes

as i told its my general observation not all from erpnext… i have used so many wordpress plugins, so many e-commerce integration tools, its just a simple harmless observation.

hiding fields one by one, really takes a lot of time. i still believe a lot of things in forms must be moved into settings section.

@fBazaar_Support I can understand that - and to some extent agree. But the trouble when you’re developing any system like this is that you’d like a particular field moved into settings or hidden, another end user will argue just as strongly that they need it to be on each record and should be handled in another way.

Both are absolutely right for their own use case. It’s why ERP systems are not designed to be used “out of the box”, they are designed to be changed / customised etc.

I would suggest that for any non-trivial business, fully implementing an ERP system is a year long project if not longer, it will take time, and it will involve resources (either financial of time). Then it needs maintaining.

1 Like

Unless something changed very-recently, it’s impossible to move standard DocFields using Customize. You can only alter their positions by editing the DocField itself (which means forking)

1 Like

I know much SAP, Oracle Fin, and Dynamics dropped mid-way but didn’t see any ERPNext project dropped.

Having said that, “bench update” erasing even minor customizations is a cause of worry. We need to find a method to keep customization intact while doing updates. i know it is easier said than done though.

It’s quite possible I’m talking rubbish here - Will go and check. So it may be I’m remembering moving fields in a custom module.

It used to be possible (version 10 or 11?) But the ability to move standard DocFields was taken away in the past version or two.

Going alone to implement erpnext is very risky lot of unanswered questions are theire, available documentation is not enough, expert rate is extremly high, finally no suitable support contract is avaipable.
Thing if you are stuck most probably you will sink alone.
I was looking for partner or frappe how I cam sign support contract but available options are not suitable at all.
Before committing you need to cover your back, if not found it’s a good reason to abandon erpnext.
Which I am stand today.

Thanks for the update.

Please don’t stereotype people based on race, gender, nationality, religion - you could have easily made the comment about UX without invoking nationality here. Please refrain from doing this again - leaving this here as an example.

18 Likes

SP-API is already implemented in separate app: feat: Amazon SP-API Integration by s-aga-r · Pull Request #161 · frappe/ecommerce_integrations · GitHub

1 Like