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ā¦