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.
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
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”.
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?)
Hub (what in earth is the Hub?)
I’m missing an index or glossary.
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”.
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)
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…
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?
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…