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!
27 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. 
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