I.e. some section on how to analyse your journal data using ledger and interpret the results would be a very nice addition to a user guide IMHO.
On Friday, October 12, 2012 2:54:25 PM UTC+2, Jeroen De Vlieger wrote: > > A word of caution the next question goes more to accounting then to the > ledger project itself :-s > > I'm not yet completely through the documentation, but I can already log my > transactions in a journal file and this is starting to fill up nicely with > data. > So now I'm coming to the point that I won't to use ledger as a tool to > manage my finances. I.e. I'm starting to think along the lines of: > + how can I use ledger help me manage my financial situation. > + how can I use ledger to help my analyse all this data and help me > prevent financial hickups instead of being forced to solve them when they > occure. > > This is also one area in which I find the documenation to be a bit lacking. > I know of the balance and register command and the -M option, but how do I > now use these to help me in my quest to manage my finances. > Which queries should I be runnig often? which reports should I be > generating to inform me of what exactlly? > > Of course you could decide that that information falls outside the scope > of ledger, but even then I would argue that references to such information > should be included in the ledger documentation, wheter it be in the > reference manual or the user guide. > > Jeroen > > On Friday, October 12, 2012 2:26:28 PM UTC+2, Jeroen De Vlieger wrote: >> >> >> >> On Friday, October 5, 2012 5:30:09 AM UTC+2, John Wiegley wrote: >>> >>> >>>>> Peter Keen <[email protected]> writes: >>> >>> > I think two main sections would be good. One section would be the >>> tutorial >>> > and "Keeping a journal with ledger" content, and the other section >>> would be >>> > strictly reference, organized by subcommand. Global options before the >>> > subcommands, subcommand-specific options within their respective >>> sections. >>> > Formatting and expressions probably deserve their own part of the >>> reference >>> > section as well. >>> >>> I agree with this. There should be a tutorial that leads into a user's >>> guide, >>> then a cookbook for typical "recipes", and finally a comprehensive >>> reference >>> on things like value expressions, query expressions, format strings, >>> etc. The >>> ref manual will naturally evolve over time, so maybe the focus right now >>> should be on the tutorial/user's guide/cookbook. Thoughts? >>> >>> John >>> >> >> That is indeed a good proposal. >> >> As a newbie to both double entry accounting an the ledger tool. >> I find that I would love to see more tutorials and recipes to do basic >> and common actions. >> a sort of user guide like John mentions that introduced concepts, cmd >> line options, value query examples in a goal driven format! >> >> Stuff like keeping track of expenses, how to do budgetting, how use the >> balance cmd effective, reconciling your bank statement, using the virtual >> accounts. >> could gradually introduce more and more options and command without >> overloading a newbie. >> This way your features are also introduced with a reason. >> >> A reference, e.g, a list of all possible cmdline options *alphabetically* >> ordered is the ideal way to go if you want to remind yourself on some >> obscure cmd option that you use only every so often. >> >> But If you are played with how to effectively implement some budget >> control, then being forced to read a reference type of work, e.g., this >> list of alphabetically ordered options and commands is rather bothersome >> and not at all motivating. It will even leaves a user iwith more questions >> than anwers, wonderiong why certain options are ever needed. And he might >> never even find out if his workflow never reaches that point where there is >> a problem that gets solved by that specific cmd or option. >> >> In those cases a refence or list of all possible options and command is >> not the right way to go. A goal driven 'user guide' how ever would be so >> much more appealing. A new user could simply learn what he needs to know by >> searching for a relevant usecase of tutorial and be remain shielded of the >> rest of the multitude of options. >> IMHO It is this kind of goal driven userguide that will be crucial for >> people giving the project an initial try to be convinced and stick with it >> instead of leaving it in favor of some other project that will hopefully be >> more user friendly to newbie's and the likes. >> >> >> >> >> A reference manual is a complete description designed to easily look >> something up >> A user guide contains the same information or more realistically part of >> it and refers to the reference manual if need be, but is designed as a >> getting started document, introducing the information grouped in a goal >> driven fashion. >> >> A reference requires that you either read it start to end in order to >> understand it, or have earlier obtained knowledge about used terms and >> concepts allowing you to understand the potentially cryptic explanations >> individual options, commands and features. >> A userguide should be structured more freely, i.e. in a way that a new >> potential user can cherry pich the use-cases and tutorials that he thinks >> will be relevant for him to get started, without the fear of missing out on >> important information by skipping certain parts or being unable to properly >> understand certain concepts. >> >> For example, what I'm lacking at the moment is some quick and dirty >> getting started guide. >> 1) How to *initialize* your journal to your current state of affairs. >> + The amount of money on your bank accounts. >> + a generally accepted workable account structure that will meet most >> initial needs to get any one started. Especially for people like me that >> are not version in accounting this turns out to be a large stumble block. >> + how to Reconcile/import historical liabilities and reimbursements >> that aren't paid off. I.e. they are liabilities and reimbursements that you >> incurred prior to staring using ledger and building jour journal file with >> transactions. >> + How to reconcile/import historical expenses to build a *partial* >> *historical* expense report. Note that these will inherently be >> *incomlete*, so reconciling might be a beter suited word then importing in >> this use case. >> >> 2) a generally accepted workflow to keep on using the ledger tool. >> This is also an issue that I still haven't yet solved satisfactorily, and >> I have been spending quite some time reading the manual. >> Examples: >> + a system on how to effectively handle receipts to keep your yournal >> up to date with minimal effort >> + a system on how te reconvile your bank statement with your journal in >> an easy enough way so that you keep on doing it. >> + a system to identify identical transactions from different sources >> and merge the information. This is where I still have lots of trouble and >> is turning out to be a large hurdle for me to solve. Source documents for >> transactions can come from a lot of different sources and they may be more >> then one document for each transaction. In those cases you need a proper >> system to successfully identify a transaction that has already be posted to >> the journal, potentially update it with some extra info included in the >> redundant source document and then simple archive the source document as >> processed. This whole workflow is one that I still find rather >> *challenging* :-s >> + procedure on how to reconcile your ledger if errors somehow crept up. >> + etc... >> >> >> sincerely, >> >> Jeroen >> >> >>
