On Sat, Oct 18, 2014 at 12:09 PM, Wm... <[email protected]> wrote:
> Fri, 17 Oct 2014 18:20:47 > <CAK21+hOUvzxe66R9jJzq0PtZJRVc=4otfkjvylo4ffagxbf...@mail.gmail.com> > Martin Blais <[email protected]> wrote... > > [GnuCash SQLite3 to Beancount] > > MartinB: > >>> You could adapt this to spit out a Beancount file if you needed to, > >>> with relatively minor changes. > > Wm: > >> I did that just the other day. Not the prettiest code / conversion but > >> the balance sheets agree afterwards not counting cosmetic presentational > >> differences. > > >That's great. > >Can you fork the project and submit your Beancount converter somewhere? > > Prefer not to as I'm sticking with GnuCash long term, I happened to be > writing some GnuCash+SQL reports for myself when I saw pygnucash > mentioned and wondered if beancount looked much different to ledger-cli > with my data. > > I've no interest in maintaining it (beancount seems to be changing file > format more actively than gnucash) and my code changes are extremely > rough, e.g. I didn't bother preserving account names nicely where > beancount is fussier than ledger-cli. > > It would make much more sense for MatzeB to have gnucash2beancount.py > alongside his gnucash2ledger.py if he is interested (although it was a > proof of concept for him AIUI) or for you to pick the working bits up. > Actually I was thinking I would just start from what you built and integrate it in my other project, LedgerHub, whose focus is on importing external data, and maintain it myself from there. The main issue I have is that I don't have a realistic GnuCash input to work from (for unit testing). The changes from MatzeB's original are: > > massage account names due to differences between ledger-cli and > beancount; you have almost certainly got a better bit of code to > do that than my effort, I just got rid of stuff in account names > as bean-check complained about it > > adjust for differences in account structure permissiveness [2] > > present commodity / currency transactions to match beancount > > I am happy to share the script with you and answer any queries you have > about the GnuCash side. > Some notes for you to consider: > > 1. bean-check makes no distinction between a warning and an error > That's on purpose. I try really hard to minimize the amount of concepts and options. Beancount operates only in "strict" mode; the input has to comply for now, I might relax this later. > 1.2 "Unused account" is not an error The way to correctly "fix" this error is by adding a plugin that will automatically remove the unused directives (I haven't done the plugin yet, so for now your list of accounts has to match, maybe I should do that). The idea is that compliant Beancount input has certain characteristics and guarantees. At the moment, one guarantee is that all accounts have a matching open directive, and that unused accounts aren't allowed. Maybe I should relax the unused accounts one though, it has been a bit annoying to me as well when doing demos. Okay, I'll think about this, this might be a bit overkill. > 1.1 "Duplicate Entry" drawing 10 cash twice in one day is not an error > Hmm, so here's the thing, in the implementation, each transaction has a unique signature, a "hash", which allows me to make comparisons between sets of transactions. The transactions will only be detected as duplicates if and only if _all_ of their fields are exactly the same. This rarely if ever happens in practice. You probably were cut-n-pasting the same transaction to test things out. The reason this exists is that it has happened a few times in the past that in the course of importing a transaction was copied twice - clearly an error. This check exists to detect this. Okay, so here's what I'm going to do: - Make the unused account check optional; it will be available through an optional plugin. - Make the duplicates check optional; similarly will be available through an optional plugin. Those who want super tight checks will have to add the options. Something like this: option "plugin" "beancount.plugins.nounused" option "plugin" "beancount.plugins.noduplicates" By default unused accounts and duplicates would be allowed. How's that? > > [2] gnc has a top level Trading account type, I chose to place them > under Equity in beancount, another person might choose to exclude them > from the conversion process [3] > Using an Equity account for GnuCash trading accounts is the correct thing to do. I'm aware of this feature, I've read the docs in the past. Beancount already automatically implements a solution similar to the foreign currency trading account method described in this document. Unlike GnuCash, you don't even have to do anything to make it work--a special "Equity:Conversions" account is added to contain the sum total of all conversions (which, if correct, should balance each other near zero, unless you did large transfers with hugely varying exchange rates). I've been referring to this issue as "the conversions problem" so far. I've been meaning to document my solution, but it's low on the list of priorities--it just works and as a user you don't have to worry about it much. You can peruse the source code in the meantime if you need the full detail. In short: Beancount inserts a special transaction that balances out the converted amounts so that the sum total of all transactions is precisely zero. > [3] as an aside I have read your critique of GnuCash in your document > about why you got started on beancount and presume you know a lot of it > doesn't apply. No, I am not trying to change your mind, just mentioning > it as gnc Trading accounts are one of the things many people don't know > about and cover some of your issues, I also consider some to be > unnecessary, but that is my problem :) > I don't know what you're talking about. In the short paragraph, I'm making the following points: - Using a language alleviates the need for inconvenient UIs - I can break GnuCash in about an hour (done this several times, as other people on this list have) What's your point? Let me know if you want the script here or by e-mail, you are better at > python than me and will make it much tidier in minutes. > If you can email the script it would save me time, thank you. Much, much more important to me is if someone could create a representative GnuCash input file that showcases a variant of every possible kind of transaction that can be done with it. I would be happy to write and maintain code to make that automatic conversion for Beancount, Ledger and HLedger. I just need some data. > > >Also, if you can identify the distinct of transactions you're using that > >would also help me create a unit test. > >Thanks, > > Most, I would have thought. GnuCash doesn't have distinct transactions > types in the sense I think you mean. > > units of stuff (e.g. currencies + commodities) seem to be what excite > you most and my beancount balance sheet agrees with gnucash apart from > the interpretational bits. > > perhaps it would be better (considering in another post you are > producing test / sample data for beancount) that you produce a "one of > each type" of transaction distinctly recognised by beancount and someone > (probably me while I am interested) will use that as a comparative. > > P.S. MatzeB if you read this will you let me know if you are interested > in having a look at my messy code? The difference really isn't worth > another project > > -- > Wm... > > -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/n4rcDlRF7pQUFwcf%40tarrcity.demon.co.uk > . > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
