We know that documentation is something users feel we need improvement on. Can we list out specific features that are not explained well enough. This is help us focussing on what needs to be fixed first.
I am a bloody newbie to ERPNext. There seems to be literally no documentation on a very high level that explains how to start using ERPNext in an easy and comprehensive way.
It’s more of a „figure it out yourself“ which is quite daunting.
Is there any high level docs for non-devs?
Update: If you read on below you will find out, that my statements are wrong. It may not be obvious to find, but the onboarding info is available.
Welcome aboard! Lots to read in the forums and the manual link is a good general start. For extra help do a search in the forums for “Step by Step” or “How to” and many links to solving common problems will populate your search.
Hey @rmehta, it’s really great you’re taking this mater serious and trying to improve the documentation. I’m happy to help by pointing out where the documentation could get some more love
Missing:
Some Terms are used but never explained.
Example: The term “module” is part of the basic concept but is not explained, not even in “Concepts And Terms”.
Module
I know there are more but I didn’t write them down. I will add them with time…
ERPNext basic concepts are missing. This would help to get a deeper knowledge about ERPNext.
Example: What is the GUIs structure and concept? ERPNext is really great in keeping it to only some different views. But these views and the concepts behind them are never really explained.
GUI and its parts
different views (List view, Doc view…)
concept behind moduls (What can I find in what module and why?)
POS (What is the envisaged way of using it? When is an other view better?)
Kanban
Hub (what in earth is the Hub?)
I’m missing an index or glossary.
Other issues:
Then there are parts that aren’t missing but have other issues:
Some parts are not going enough into detail. If it’s to broad it’s not usable as a manual.
Example: Is that really all there is to say about Offline POS? What happens with the data? When and how is it synced? …
Offline POS : In the retails business, invoicing needs to done very quickly, hence should less dependency. In the ERPNext, you can create POS Invoices, even when not connected to the internet.
Explanation of the fields are not consistent. For some the manual says “what it is”, for some it says “how to use it”.
Example: Item
Default Expense Account: It is the account in which cost of the Item will be debited. Default Cost Centre: It is used for tracking expense for this Item.
Often field names that are explained in the manual aren’t the same in EPRNext
Example: Item: Customer Codes instead of Customer Item Codes
Some fields are not explained at all.
Exampel: Item: Delivered by Supplier (Drop Ship)
General format:
IMHO to get not only a complete but a good documentation has more to do with HOW it’s written, the general format. Let me explain that:
If you look at a good software manual (as well as good non-fiction books) as a reader you realize quickly the structure of the book. Every chapter often starts at the bigger picture and then slowly takes you to the details. A great example is the documentation of GnuCash, they even explain their concept.
The manual for ERPNext has no such structure (or it’s not consistent). That makes it harder to read but also results in lots of missing things or inconsistent parts. But that will be a much bigger take…
Your answer is so detailed and specific that I ask myself if you personally couldn‘t be convinced to contribute more to it. Change specific things via github is a matter of two clicks …
Yes, you’re absolutely right! I should and I actually started to do that. At least with smaller things like field names etc.
For the rest I have to problems:
English isn’t my mother tongue. Writing a manual in English will take me ages (yes, these posts also take some time…) and the language quality will at least be questionable.
If I could write the manual in German, that would be an other story. But then the problem would be about translating it to English…
The things I’m missing in the documentation are also the things I don’t understand. Because there is no documentation I can read about it. See my point?
So I’m stock with changing the small bits and pointing out the bigger ones…
At least I don’t see a better solution. Do you?
Customer Sagar Malhotra has purchased Nokia Lumia worth Rs 42,400 and at the time of delivery customer were found that the piece has been damaged.
in your English manual here. For a western audience the first name “Sagar” is unfamiliar. We do not even know, if this is a man or a woman.
My question is: “Who do you want to address first? Who is your main target group?” The biggest market is probably USA. So maybe such a sentence could be changed as follows:
Your customer John Smith has purchased an Android smartphone worth $424 and at the time of delivery customer were found that the piece has been damaged.
Is that leading in the right direction? Keeping it more tailored to the Indian market as the root for the software may have upsides as well. What’s your take on this?
This is a tough one! I would love names to be global.
Maybe lets use various kinds of names and currencies, so there is representation from all kinds of the world. Or maybe we can avoid names altogether. Or use it from an imaginary universe like the Harry Potter universe.
Either ways, no special preferences as long as it explains well.
I like the approach with a common story. Star Wars is both popular with older and younger people and has a small geek factor. I also like the inclusive „all kinds of people“. But we need to add „Mr.“ and „Mrs.“ or „Ms.“ for a better understanding with uncommon first names.
API documentation could be more integrated to the doctype documentation,
Previously I used NetSuite, the way they do documentations is they explain the “Transactions” (doctypes), and then they have a page that describes all the APIs that that particular transaction have and their examples…
I don’t come from engineering background, but it seems like our developers find this easier…