Budgets ... again

[Tiago Neiva]

I myself have been considering some sort of extraction tool, not for
budgeting but for mining the data. most of us use spreadsheets to do the
graphs and to have the data closed up in gnucash is my biggest problem.

I will check your project for sure, use it and probably translate it if I
see a  possible use in PT.


On Sun, Sep 11, 2011 at 5:00 PM, <gnucash-devel-request at gnucash.org> wrote:

> Send gnucash-devel mailing list submissions to
>        gnucash-devel at gnucash.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> or, via email, send a message with subject or body 'help' to
>        gnucash-devel-request at gnucash.org
>
> You can reach the person managing the list at
>        gnucash-devel-owner at gnucash.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gnucash-devel digest..."
>
>
> Today's Topics:
>
>   1. Budgets ... again (Wm Tarr)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 11 Sep 2011 12:55:31 +0100
> From: Wm Tarr <wm.tarr at gmail.com>
> To: gnucash-devel at gnucash.org
> Subject: Budgets ... again
> Message-ID: <4E6CA1B3.1070400 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I know GnuCash and budgeting is a perennial issue.  I haven't seen what
> I suggest below covered before and welcome pointers if that is not the
> case.
>
> 1.  GnuCash's current budgeting tools are dismal; they are hard to work
> out how to use and even when you know how to use them they don't do what
> you expect. [1]
>
> [1] I had to look at the tables to work out where the various bits of a
> budget were stored.  Who had the bright idea of putting stuff in the
> recurrences table that should be somewhere else?  The design is broken
> for starters.
>
> 2. Given that there has been considerable discussion about GnuCash and
> budgets in the past and that a number of people have argued one way or
> another isn't it time for budgeting to be independent of GnuCash?
>
> 3. I have been pulling data out of GnuCash for years now (hand written
> scripts for XML and now SQL) in order to get it into a form suitable for
> use in a spreadsheet so I can ... yes, you guessed it ... do some
> budgeting.
>
> 4. My scripts have (and do) served me well but I want a better interface
> to them so I have started writing an application or tool (call it what
> you will) that allows for more.
>
> 5. Say hello to gncb (that is what I have named my project) it is a
> webapp (no reason why it couldn't use a more conventional UI but I
> wanted to play with that and found some handy tools).
>
> 6. Before you ask ... Q: Will you write back to the GnuCash db?  A: I
> can but don't see the point as GnuCash doesn't really do anything useful
> with budgets so there is little point, much more useful to export and
> import into a prog or tool that allows you to do what you want ... or
> you can pick up on my idea and help me with that.
>
> 7. Some philosophy: GnuCash isn't what
> http://en.wikipedia.org/wiki/Gnucash says any more, it is no longer a
> Quicken wannabe.  That doesn't mean that people that want to have YNAB,
> MS Money, etc. type budgeting shouldn't be allowed that.  I differ from
> some other people in thinking that the budgeting need not be part of
> GnuCash because whatever GnuCash does wrt budgeting won't be to
> someone's liking.so why start doing something that will upset someone else?
>
> 8. An external budgeting system allows for adaptation and enhancement by
> anyone while maintaining the core goodness of GnuCash.
>
> 9. A comment on tools used so far: SQLite (if you use a modern browser
> you are using SQLite whether you know it or not so that isn't a surprise
> requirement, can't really think why GnuCash should be in MySQL or PG to
> be honest); perl (but there is no reason why any other language couldn't
> be used or even something compiled once we have a working model (I have
> that already, I just don't know if other people are interested or
> not).); a web browser like FireFox or any of its relations and you're done.
>
> 10. Comment: my background is in business rather than personal money
> matters.  I don't see why good principles can't be transferred from one
> domain to another.
>
> 11. Comments, critisism, etc. welcomed.
> --
> Wm ...
>
>
>
> ------------------------------
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
> End of gnucash-devel Digest, Vol 102, Issue 7
> *********************************************
>



-- 
 Tiago Neiva
---------------
Help Stamp out SPAM !
- Por favor NÃO reencaminhe mensagens de remetentes desconhecidos;
- Ao responder a endereços conhecidos, apague as referências de endereços em
CC: ou na mensagem;
- Esconda os endereços dos destinatários usando os campos de endereço Bcc:
ou CCo: em vez de usar os campos To: ou Cc:

- Please do NOT forward messages coming from unknown senders;
- When replying to known senders, delete all other address references from
CC or body;
- Hide all destination addresses by using fields Bcc or CCo, instead of To: