"No position matches" error confuses noob.

1,392 views
Skip to first unread message

sm...@davethehappysinger.com

unread,
Jun 12, 2017, 12:48:46 AM6/12/17
to Beancount
Hi there,

I'm new to beancount and I'm trying to use it to bring sanity to some old Bitcoin transactions.

I start off making the odd purchase of BTC in Australian dollars using the Coinjar service with one beancount account for BTC and one for AUD.

However, once I move 1.0 BTC out of my Coinjar BTC account into a paper wallet, subsequent purchases throw an error in bean-check:

No position matches "Posting(account='Assets:AU:Coinjar:BTC', units=0.162288 BTC, cost=CostSpec(number_per=Decimal('924.2827565808932268559597752'), number_total=None, currency='AUD', date=None, label=None, merge=False), price=None, flag=None, meta={'lineno': 24, 'filename': '/home/dave/fin/accounts/bitcoin-test.beancount'})" against balance (-1.0 BTC, 0.230398 BTC {651.0473181190808947994340229 AUD, 2013-12-19}, 0.673358 BTC {742.5470552068884605217432629 AUD, 2013-12-17}, 0.149156 BTC {1005.658505189197886776261096 AUD, 2013-12-10}, 0.14161 BTC {1059.247228303085940258456324 AUD, 2013-11-27}, 0.118776 BTC {1262.881390179834309961608406 AUD, 2013-11-29})

But of course no existing position matches; this is a new lot I'm purchasing. Here's a simple sample file to reproduce. Could someone perhaps clarify where I've gone wrong? Thanks for your time; I've read the documentation on booking trades several times but I'm afraid I can't make sense of this error.


2013-11-27 open Assets:AU:Coinjar:BTC  BTC
2013-11-27 open Assets:AU:Coinjar:Cash AUD
2013-11-27 open Assets:AU:ColdStorage:BTC BTC


2013-11-27 * "Buy BTC"
  Assets:AU:Coinjar:BTC                         0.14161 BTC {1059.247228303085940258456324 AUD}
  Assets:AU:Coinjar:Cash                     -150.00 AUD
2013-11-29 * "Buy BTC"
  Assets:AU:Coinjar:BTC                         0.118776 BTC {1262.881390179834309961608406 AUD}
  Assets:AU:Coinjar:Cash                     -150.00 AUD
2013-12-10 * "Buy BTC"
  Assets:AU:Coinjar:BTC                         0.149156 BTC {1005.658505189197886776261096 AUD}
  Assets:AU:Coinjar:Cash                     -150.00 AUD
2013-12-17 * "Buy BTC"
  Assets:AU:Coinjar:BTC                         0.673358 BTC {742.5470552068884605217432629 AUD}
  Assets:AU:Coinjar:Cash                     -500.00 AUD
2013-12-19 * "Buy BTC"
  Assets:AU:Coinjar:BTC                         0.230398 BTC {651.0473181190808947994340229 AUD}
  Assets:AU:Coinjar:Cash                     -150.00 AUD
2014-01-05 * "Deposit Cold storage"
  Assets:AU:ColdStorage:BTC                     1.0 BTC
  Assets:AU:Coinjar:BTC                        -1.0 BTC
; The following tx now throws an error though it is syntactically identical to the
; purchases above. Why?
2014-01-28 * "Buy BTC"
  Assets:AU:Coinjar:BTC                         0.162288 BTC {924.2827565808932268559597752 AUD}
  Assets:AU:Coinjar:Cash                     -150.00 AUD

Martin Blais

unread,
Jun 12, 2017, 11:17:57 PM6/12/17
to Beancount
(Apologies for the long response, you've triggered an interesting corner case which may require a fix.)

The error you made here (deducting 1.0 BTC from the account with existing positions without specifying the cost basis) brings up an interesting corner case.


The following is sufficient to trigger the error:


2013-11-27 open Assets:AU:Coinjar:BTC  BTC
2013-11-27 open Assets:AU:Coinjar:Cash AUD
2013-11-27 open Assets:AU:ColdStorage:BTC BTC

2014-01-05 * "Deposit Cold storage"
  Assets:AU:ColdStorage:BTC                     1.0 BTC
  Assets:AU:Coinjar:BTC                        -1.0 BTC

2014-01-28 * "Buy BTC"
  Assets:AU:Coinjar:BTC                         0.162288 BTC {924.2827565808932268559597752 AUD}
  Assets:AU:Coinjar:Cash                     -150.00 AUD


What's happening is that after the first transaction the Coinjar:BTC account contains a negative number of units of BTC:

bean-doctor context smile1.beancount 6
Hash:f7a2fba6639dd0ec5d52abce3788f32d
Location: /home/blais/r/q/beancount-data/user/smile/smile1.beancount:5

------------ Balances before transaction

  Assets:AU:ColdStorage:BTC

  Assets:AU:Coinjar:BTC


------------ Transaction

2014-01-05 * "Deposit Cold storage"
  Assets:AU:ColdStorage:BTC   1.0 BTC
  Assets:AU:Coinjar:BTC      -1.0 BTC


Tolerances: BTC=0.05

------------ Balances after transaction

* Assets:AU:ColdStorage:BTC                                            1.0 BTC

* Assets:AU:Coinjar:BTC                                               -1.0 BTC


"Adding" BTC to this negative inventory essentially means a "reduction" of the negative number of BTC (you're reducing the short position).
Since the second transaction is providing a cost basis and it has only a single lot with no cost basis, it cannot find a lot that matches, so you get an error.
This is WAI.
(But it does beg the question regarding whether lots without a cost basis should be treated distinctly; so far I'm not convinced that they should, I don't have a great use case for that, so they're not.)



If I leave all the previous transactions, one gets into a slightly different case:

bean-doctor context smile1.beancount 27
Hash:f7a2fba6639dd0ec5d52abce3788f32d
Location: /home/blais/r/q/beancount-data/user/smile/smile1.beancount:26

------------ Balances before transaction

  Assets:AU:ColdStorage:BTC

  Assets:AU:Coinjar:BTC      0.14161 BTC {1059.247228303085940258456324 AUD, 2013-11-27}
  Assets:AU:Coinjar:BTC      0.118776 BTC {1262.881390179834309961608406 AUD, 2013-11-29}
  Assets:AU:Coinjar:BTC      0.149156 BTC {1005.658505189197886776261096 AUD, 2013-12-10}
  Assets:AU:Coinjar:BTC      0.673358 BTC {742.5470552068884605217432629 AUD, 2013-12-17}
  Assets:AU:Coinjar:BTC      0.230398 BTC {651.0473181190808947994340229 AUD, 2013-12-19}


------------ Transaction

2014-01-05 * "Deposit Cold storage"
  Assets:AU:ColdStorage:BTC   1.000000 BTC
  Assets:AU:Coinjar:BTC      -1.000000 BTC


Tolerances: BTC=0.05

------------ Balances after transaction

* Assets:AU:ColdStorage:BTC                                            1.0 BTC

  Assets:AU:Coinjar:BTC      0.14161 BTC {1059.247228303085940258456324 AUD, 2013-11-27}
  Assets:AU:Coinjar:BTC      0.118776 BTC {1262.881390179834309961608406 AUD, 2013-11-29}
  Assets:AU:Coinjar:BTC      0.149156 BTC {1005.658505189197886776261096 AUD, 2013-12-10}
  Assets:AU:Coinjar:BTC      0.673358 BTC {742.5470552068884605217432629 AUD, 2013-12-17}
  Assets:AU:Coinjar:BTC      0.230398 BTC {651.0473181190808947994340229 AUD, 2013-12-19}
* Assets:AU:Coinjar:BTC                                               -1.0 BTC


Here, in theory (excluding the last transaction), there are enough BTC to cover the -1.0 reduction and keep the balance positive:

bean-query smile1.beancount "select account, sum(units(position)) group by 1"
         account          sum_units_positi
------------------------- ----------------
Assets:AU:Coinjar:BTC         0.313298 BTC
Assets:AU:Coinjar:Cash    -1100.00     AUD
Assets:AU:ColdStorage:BTC     1.0      BTC


The real problem is that the transaction removing -1.0 BTC from the Coinjar:BTC should have failed and raised an error message. It's a bug that it did not (I'll have to address that; I'm quite surprised this wasn't covered by my unit tests - thanks for bringing up that question).

Ticket:

Now, with the default booking method (STRICT) If you reduce an existing position, you should have to provide the cost basis you want to book against. Given the frequency with which those transactions appear to occur, explicitly selecting each of the lots to reduce in order to move your 1.0 BTC to cold storage would be a pain in the butt. I think you'll want something easier. 

Normally, you can set that account's booking algorithm to something else, e.g. "FIFO", which would select the lots for you:

2013-11-27 open Assets:AU:Coinjar:BTC  BTC  "FIFO"
...
2014-01-05 * "Deposit Cold storage"
  Assets:AU:ColdStorage:BTC                     1.0 BTC
  Assets:AU:Coinjar:BTC                        -1.0 BTC {}


But this appears to trigger another bug!
Congratulations, you've found two at once (finding one is reasonably rare these days).



I'm going to fix those, but in any case, you shouldn't be able to reduce an inventory with lots with -1.0 BTC.
Either you'll have to select the lots explicltly, or let one of the automatic booking methods do it for you.
In any case, you should probably never mix operations at cost (with {...}) with those not at cost (without {...}) on a single account.

In the meantime, you can disable the booking algorithm by setting the method to "NONE":

2013-11-27 open Assets:AU:Coinjar:BTC  BTC  "NONE"
...
2014-01-05 * "Deposit Cold storage"
  Assets:AU:ColdStorage:BTC                     1.0 BTC
  Assets:AU:Coinjar:BTC                        -1.0 BTC 

This effectively replicates the Ledger model. The resulting inventory will have all the transactions in it, and you can sum up the resulting number of UNITS() or COST() and these numbers will be correct. However, the detailed contents of the inventory will appear messy. But it works.

I think the way forward is for me to fix the two bugs and for you to use the FIFO method thereafter.

Or... it's also possible that you're not attempting to track cost basis.
If that's the case you can just use price conversions (with @ ...).
If you used price conversions, there are no lots (well, just a single lot with no cost basis).

I hope this helps,





--
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 beancount+unsubscribe@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/2beb84b0-8f10-4c40-b6d5-abfa2b77cda5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Martin Blais

unread,
Jun 12, 2017, 11:26:35 PM6/12/17
to Beancount
One more thing: If you disambiguate the cost currency in your reducing transaction, the FIFO method is working fine:


2013-11-27 open Assets:AU:Coinjar:BTC  BTC "FIFO"
...
2014-01-05 * "Deposit Cold storage"
  Assets:AU:ColdStorage:BTC                     1.0 BTC {}
  Assets:AU:Coinjar:BTC                        -1.0 BTC {AUD}


Or if you don't care about the cost basis in ColdStorage (you lose it):

2013-11-27 open Assets:AU:Coinjar:BTC  BTC "FIFO"
...
2014-01-05 * "Deposit Cold storage"
  Assets:AU:ColdStorage:BTC                     1.0 BTC @
  Assets:AU:Coinjar:BTC                        -1.0 BTC {AUD}

This also works:

2014-01-05 * "Deposit Cold storage"
  Assets:AU:ColdStorage:BTC                     1.0 BTC @ AUD
  Assets:AU:Coinjar:BTC                        -1.0 BTC {}


Both of these do what you'd expect them to, that is, it gets translated to this transaction:

Hash:c33deeb52a4546640770ddbe49eeb805
Location: /home/blais/r/q/beancount-data/user/smile/smile1.beancount:25

------------ Balances before transaction

  Assets:AU:ColdStorage:BTC

  Assets:AU:Coinjar:BTC      0.14161 BTC {1059.247228303085940258456324 AUD, 2013-11-27}
  Assets:AU:Coinjar:BTC      0.118776 BTC {1262.881390179834309961608406 AUD, 2013-11-29}
  Assets:AU:Coinjar:BTC      0.149156 BTC {1005.658505189197886776261096 AUD, 2013-12-10}
  Assets:AU:Coinjar:BTC      0.673358 BTC {742.5470552068884605217432629 AUD, 2013-12-17}
  Assets:AU:Coinjar:BTC      0.230398 BTC {651.0473181190808947994340229 AUD, 2013-12-19}


------------ Transaction

2014-01-05 * "Deposit Cold storage"
  Assets:AU:ColdStorage:BTC   1.000000 BTC @ 888.4428491233489466227474835 AUD  ;  888.4428491233489466227474835 AUD
  Assets:AU:Coinjar:BTC      -0.141610 BTC {1059.25 AUD, 2013-11-27}            ; -150.0000000000000000000000000 AUD
  Assets:AU:Coinjar:BTC      -0.118776 BTC {1262.88 AUD, 2013-11-29}            ; -150.0000000000000000000000000 AUD
  Assets:AU:Coinjar:BTC      -0.149156 BTC {1005.66 AUD, 2013-12-10}            ; -150.0000000000000000000000000 AUD
  Assets:AU:Coinjar:BTC      -0.590458 BTC {742.55 AUD, 2013-12-17}             ; -438.4428491233489466227474835 AUD


Tolerances: BTC=0.000005
Basis: (-888.4428491233489466227474835 AUD)

------------ Balances after transaction

* Assets:AU:ColdStorage:BTC                                            1.0 BTC

* Assets:AU:Coinjar:BTC      0.082900 BTC {742.5470552068884605217432629 AUD, 2013-12-17}
  Assets:AU:Coinjar:BTC      0.230398 BTC {651.0473181190808947994340229 AUD, 2013-12-19}



And the following one succeeds just fine.

I think this is the best solution of all ofthose, just 
- make sure you use cost basis consistently
- clearly indicate the cost currency when you're using automatic matching / inference

I'll fix the tickets anyhow, but if you do this, nothing should change.




Dave The Happy Singer

unread,
Jun 13, 2017, 12:03:42 AM6/13/17
to Beancount
Hi Martin,

Thanks so much for the very thorough responses. I'm glad (?) I could help you find some issues to fix. I'll sit down and digest your solutions in more depth this evening and follow the tickets in case I need them. I'm sure I'll be able to get things moving with the information you've provided.

(I was vaguely aware of plaintext accounting but I only properly discovered it this weekend and I'm excited by the possibilities. I'm a Python dev so hopefully once I've got my head around the conceptual stuff I hope I'll be able to contribute back in some way).

Thanks again for you time!

Dave

To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/2beb84b0-8f10-4c40-b6d5-abfa2b77cda5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/Qvbcq-Sk5NY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

Daniël Bos

unread,
Jun 13, 2017, 12:38:17 AM6/13/17
to Beancount
Hi Dave,

If you haven't come across it yet, you might be interested in Fava [1] as well. It's a web-wrapper (using on Flask) around Beancount, providing you a convenient way to record transactions and generate various reports. It's intended to make the barrier of entry to using plaintext accounting as low as possible, without preventing you from using the more powerful features such as scripting and plugins.


To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscribe@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/2beb84b0-8f10-4c40-b6d5-abfa2b77cda5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/Qvbcq-Sk5NY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+unsubscribe@googlegroups.com.

--
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 beancount+unsubscribe@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Best regards,
Daniël Bos


Your government is reading your email. Slow them down with encryption.

My public key: http://goo.gl/gms497 (4096 bit RSA, id EF2D5D91)
Fingerprint  : D8D0 9FBE F075 F709 7B52  2F73 326C 2123 EF2D 5D91

Dave The Happy Singer

unread,
Jun 13, 2017, 12:49:56 AM6/13/17
to Beancount
Hey Daniël,

Thanks a lot but yep, I've already got Fava installed and I've started playing with it. I can see it's going to be really useful for ad-hoc stuff and for getting to grips with the fundamentals. I'm looking forward to it. As, I imagine, my tax accountant would be if he knew I was motivated for once...

To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/2beb84b0-8f10-4c40-b6d5-abfa2b77cda5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/Qvbcq-Sk5NY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.

--
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 beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Best regards,
Daniël Bos


Your government is reading your email. Slow them down with encryption.

My public key: http://goo.gl/gms497 (4096 bit RSA, id EF2D5D91)
Fingerprint  : D8D0 9FBE F075 F709 7B52  2F73 326C 2123 EF2D 5D91

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/Qvbcq-Sk5NY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

samue...@gmail.com

unread,
Aug 11, 2018, 10:18:46 PM8/11/18
to Beancount
Just wanted to alert you to another potential issue and say that this solution worked for me and thank you.

So this worked for me:
    2017-06-14 * "Transfer"
      Assets:BTC:Coinbase                                         -0.00144853 BTC {}
      Expenses:Fees:BTCMining                                      0.00105853 BTC
      Assets:BTC:Jaxx                                                 0.00039 BTC @ USD

But this does not:
    2017-06-14 * "Transfer"
      Assets:BTC:Coinbase                                         -0.00144853 BTC {}
      Expenses:Fees:BTCMining                                      0.00105853 BTC
      Assets:BTC:Jaxx                                                 0.00039 BTC @

And actually raises an error when I run bean-check on it:

    Traceback (most recent call last):
      File "/home/salotz/anaconda3/bin/bean-check", line 6, in <module>
        sys.exit(main())
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/scripts/check.py", line 40, in main
        extra_validations=validation.HARDCORE_VALIDATIONS)
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/loader.py", line 90, in load_file
        _log_errors(errors, log_errors)
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/loader.py", line 128, in _log_errors
        printer.print_errors(errors, file=log_errors)
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/parser/printer.py", line 437, in print_errors
        output.write(format_error(error))
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/parser/printer.py", line 407, in format_error
        error_string = '\n'.join(format_entry(entry) for entry in entries)
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/parser/printer.py", line 407, in <genexpr>
        error_string = '\n'.join(format_entry(entry) for entry in entries)
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/parser/printer.py", line 332, in format_entry
        return EntryPrinter(dcontext, render_weights)(entry)
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/parser/printer.py", line 117, in __call__
        method(obj, oss)
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/parser/printer.py", line 169, in Transaction
        for posting in entry.postings]
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/parser/printer.py", line 169, in <listcomp>
        for posting in entry.postings]
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/parser/printer.py", line 230, in render_posting_strings
        weight_str = str(convert.get_weight(posting))
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/core/amount.py", line 70, in __str__
        return self.to_string()
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/core/amount.py", line 61, in to_string
        return "{} {}".format(dformat.format(self.number, self.currency),
      File "/home/salotz/anaconda3/lib/python3.6/site-packages/beancount/core/display_context.py", line 368, in format
        return func(number)
    TypeError: unsupported format string passed to type.__format__


Also one other case to consider is in inference of the actual posting amounts, say:
    2017-06-14 * "Transfer"
      Assets:BTC:Coinbase                                         -0.00144853 BTC {}
      Expenses:Fees:BTCMining                                      0.00105853 BTC
      Assets:BTC:Jaxx

Which is what I originally wanted to do because I don't know the exact amount posted to the Assets:BTC:Jaxx wallet.

Of course I figured it out by hand but I had to make sure I got the rounding exactly right...

So I think there is a use case for this. I imagine though this would be hard to implement since it would have to introduce some new syntax where you can allow:
    2017-06-14 * "Transfer"
      Assets:BTC:Coinbase                                         -0.00144853 BTC {}
      Expenses:Fees:BTCMining                                      0.00105853 BTC
      Assets:BTC:Jaxx                                                  @ USD

Or something similar. I actually tried for the heck of it and again there is an error when I run bean-check.

I don't know anything about how the lexer works, but perhaps this could be implemented with a flag for the posting to explicitly make it an estimated amount posting and allow missing numbers syntax after it.

    2017-06-14 * "Transfer"
      Assets:BTC:Coinbase                                         -0.00144853 BTC {}
      Expenses:Fees:BTCMining                                      0.00105853 BTC
      @ Assets:BTC:Jaxx                                                  @ USD


or I guess if the original bug is fixed you could simply have:
    2017-06-14 * "Transfer"
      Assets:BTC:Coinbase                                         -0.00144853 BTC {}
      Expenses:Fees:BTCMining                                      0.00105853 BTC
      @ Assets:BTC:Jaxx                                                 


Thanks again for the great project, I've learned so much about accounting from the docs and google group alone as well feeling like I'm actually managing the financial demon.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

samue...@gmail.com

unread,
Aug 11, 2018, 10:39:25 PM8/11/18
to Beancount

I lied I was missing the new error message:

    /home/salotz/tree/personal/studio/projects/index/finance/ledger/ledger.beancount:1161:    Transaction does not balance: (0.00105853 BTC)

       2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

         Expenses:Fees:BTCMining   0.00105853 BTC                                   
         Assets:BTC:Coinbase      -0.00144853 BTC {2661.48 USD, 2017-06-14}         
         Assets:BTC:Jaxx              0.00039 BTC @ 9885.214421538461538461538462 USD


Upon investigation in bean-doctor:

    ------------ Balances before transaction

      Expenses:Fees:BTCMining                                                  

      Assets:BTC:Coinbase                 0.004151 BTC {2247.70 USD, 2017-05-24}
      Assets:BTC:Coinbase               0.01878653 BTC {2661.48 USD, 2017-06-14}

      Assets:BTC:Jaxx                                                          


    ------------ Transaction

    2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
      Expenses:Fees:BTCMining   0.00105853 BTC                            ;                    0.00105853 BTC
      Assets:BTC:Coinbase      -0.00144853 BTC {2661.48 USD, 2017-06-14}  ;                 -3.8552336244 USD
      Assets:BTC:Jaxx           0.00039000 BTC @ 9885.21 USD              ; 3.855233624400000000000000000 USD


    Residual: (0.00105853 BTC)
    Tolerances: BTC=5E-9
    Basis: (-3.8552336244 USD)

    ------------ Balances after transaction

    * Expenses:Fees:BTCMining                                     0.00105853 BTC

      Assets:BTC:Coinbase                 0.004151 BTC {2247.70 USD, 2017-05-24}
    * Assets:BTC:Coinbase               0.01733800 BTC {2661.48 USD, 2017-06-14}

    * Assets:BTC:Jaxx                                                0.00039 BTC


It seems that it is booking the lot from Assets:BTC:Coinbase all to Assets:BTC:Jaxx because of the use of that syntax, and then the mining fee leg is unbalanced and not considered at all. So I tried:

    2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

      Assets:BTC:Coinbase                                         -0.00144853 BTC {}
      Expenses:Fees:BTCMining                                      0.00105853 BTC @ USD

      Assets:BTC:Jaxx                                                 0.00039 BTC @ USD

And to reverse the autofilling of the amount:

    2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

      Assets:BTC:Coinbase                                         -0.00144853 BTC {}
      Expenses:Fees:BTCMining
      Assets:BTC:Jaxx                                                 0.00039 BTC @ USD


But I get this error for both:

    /home/salotz/tree/personal/studio/projects/index/finance/ledger/ledger.beancount:1163:    Too many missing numbers for currency group 'USD'

Not sure what to do at this point except for booking the mining fee in a separate transaction.

Martin Blais

unread,
Aug 12, 2018, 4:02:23 PM8/12/18
to Beancount
On Sat, Aug 11, 2018 at 10:18 PM <samue...@gmail.com> wrote:
Just wanted to alert you to another potential issue and say that this solution worked for me and thank you.

So this worked for me:
    2017-06-14 * "Transfer"
      Assets:BTC:Coinbase                                         -0.00144853 BTC {}
      Expenses:Fees:BTCMining                                      0.00105853 BTC
      Assets:BTC:Jaxx                                                 0.00039 BTC @ USD

This would only work is there is some USD currency present in CoinBase at the time of applying this transaction.

 

But this does not:
    2017-06-14 * "Transfer"
      Assets:BTC:Coinbase                                         -0.00144853 BTC {}
      Expenses:Fees:BTCMining                                      0.00105853 BTC
      Assets:BTC:Jaxx                                                 0.00039 BTC @

Yep, there are two currency groups here:
- whatever was in the CoinBase account, if there's a single cost currency
- BTC, from the second leg.
So what should be the third leg?

Interpolation is flexible, but not infinitely so.
There are many cases it doesn't handle.


And actually raises an error when I run bean-check on it:

I'm not able to reproduce this error.
Could you provide a minimal Beancount input that triggers this?
How is Beancount supposed to know which currency it need to convert to in Jaxx?
You have USD (presumably), from the first posting,
then you have some BTC from the second.
This would deposit both of these in the third account, resulting in mixed currencies.

 

Martin Blais

unread,
Aug 12, 2018, 4:20:22 PM8/12/18
to Beancount
I read what you wrote three times and I don't understand what you're saying.
In any case, here's how this works: in this transaction:

       2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
         Expenses:Fees:BTCMining   0.00105853 BTC                                    
         Assets:BTC:Coinbase      -0.00144853 BTC {2661.48 USD, 2017-06-14}          
         Assets:BTC:Jaxx              0.00039 BTC @ 9885.214421538461538461538462 USD

- The first posting "weighs" for  0.00105853 BTC
- The second posting "weighs" for -0.00144853 BTC x 2661.48 USD = -3.8552336244 USD
- The first postings "weights" for 0.00039 BTC @ 9885.214421538461538461538462 USD = 3.8552336244 USD

So it has two currency groups to balance:
1. USD, with the two legs cancelling each other out: -3.8552336244 + 3.8552336244 = 0, so we're goot.
2. BTC, of which there is a single leg and the amount (0.00105853) exceeds the tolerance, so BTC is not balanced.
So you get an error.

One way to achieve what you want is this: keep the cost basis in Jaxx and book your expenses as BTC without cost basis

2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

  Expenses:Fees:BTCMining   0.00105853 BTC @ USD

  Assets:BTC:Coinbase      -0.00144853 BTC {2661.48 USD}

  Assets:BTC:Jaxx              0.00039 BTC {2661.48 USD}


Unfortunately, you cannot leave more than one number to be interpolated in each currency group.


 
So I tried:

    2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
      Assets:BTC:Coinbase                                         -0.00144853 BTC {}
      Expenses:Fees:BTCMining                                      0.00105853 BTC @ USD
      Assets:BTC:Jaxx                                                 0.00039 BTC @ USD

And to reverse the autofilling of the amount:

    2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
      Assets:BTC:Coinbase                                         -0.00144853 BTC {}
      Expenses:Fees:BTCMining
      Assets:BTC:Jaxx                                                 0.00039 BTC @ USD


But I get this error for both:

    /home/salotz/tree/personal/studio/projects/index/finance/ledger/ledger.beancount:1163:    Too many missing numbers for currency group 'USD'

Beancount only supports a single interpolated number by currency group to balance.
It's a very complicated answer to explain why, but essentially revolves around the fact that the problem is underconstrained.

 

Not sure what to do at this point except for booking the mining fee in a separate transaction.

Cryptocurrencies offer a particular challenge in that reductions at cost basis are made as often as expenses for some users.
Beancount isn't particularly well adapted to that (but nothing else is either).
See another recent-ish thread on Bitcoin.




--
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 beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.

Samuel Lotz

unread,
Aug 13, 2018, 10:37:49 PM8/13/18
to bean...@googlegroups.com
Hi Martin,
Apologies that its not very understandable, I honestly was a little confused myself.

Your solution works for me exactly as I want, however, then I am losing the convenience of using the booking method (LIFO in my case). I tried this:

 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
   Expenses:Fees:BTCMining                                  0.00105853 BTC @ BTC

   Assets:BTC:Coinbase                                     -0.00144853 BTC {}
   Assets:BTC:Jaxx                                             0.00039 BTC {}

But I get an error in bean-check.

I would imagine that this would have the same effect because the cost basis for the lot would be filled in automatically, but I figured disambiguating would help like this:

 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
   Expenses:Fees:BTCMining                                  0.00105853 BTC @ BTC
   Assets:BTC:Coinbase                                     -0.00144853 BTC {USD}
   Assets:BTC:Jaxx                                             0.00039 BTC {USD}



But it books the cost-basis of the BTC in the Jaxx account as 9885.214421538461538461538462 USD :

--> bean-doctor context ledger.beancount 107
Hash:972251de2efc72a4e7f2a2c4654440cb
Location: /home/salotz/tree/personal/studio/projects/index/troubleshooting.general/beancount/issue_000/ledger.beancount:107


------------ Balances before transaction

  Expenses:Fees:BTCMining                                                  

  Assets:BTC:Coinbase               0.01878653 BTC {2661.48 USD, 2017-06-14}

  Assets:BTC:Jaxx                                                          


------------ Transaction

2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
  Expenses:Fees:BTCMining   0.00105853 BTC @ 0.00000000 BTC           ;                             0 BTC

  Assets:BTC:Coinbase      -0.00144853 BTC {2661.48 USD, 2017-06-14}  ;                 -3.8552336244 USD
  Assets:BTC:Jaxx           0.00039000 BTC {9885.21 USD, 2017-06-14}  ; 3.855233624400000000000000000 USD


Tolerances: BTC=5E-9


------------ Balances after transaction

* Expenses:Fees:BTCMining                                     0.00105853 BTC

* Assets:BTC:Coinbase               0.01733800 BTC {2661.48 USD, 2017-06-14}

* Assets:BTC:Jaxx          0.00039 BTC {9885.214421538461538461538462 USD, 2017-06-14}

Maybe I am mistaken and this is correct but it doesn't seem to me since then if you sold the position in the Jaxx wallet it wouldn't be booked against the original cost-basis that was calculated when the lot was bought.

I've attached a minimum working example for a lot of test cases and their results written in the comments. It may not be of much use to you though, but when I don't understand something I tend to go for the enumerative brute force and try to understand the results and compare.

My conclusions are that in a single transaction directive it is not possible to automatically (i.e. not specify the position to reduce against) split an inventory reduction into an expense and an asset transfer and keep the original cost-basis.

I tried splitting it into two transactions and this seems to work swimmingly, so this is the way I will do it for now until the booking capabilities are more advanced.

I really appreciate your responses.

~Sam

To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscribe@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/0a916715-69ab-4337-b327-c256aa3e1f3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/Qvbcq-Sk5NY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+unsubscribe@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
ledger.beancount

Martin Blais

unread,
Aug 14, 2018, 12:10:02 AM8/14/18
to Beancount
On Mon, Aug 13, 2018 at 10:37 PM Samuel Lotz <samue...@gmail.com> wrote:
Hi Martin,
Apologies that its not very understandable, I honestly was a little confused myself.

Your solution works for me exactly as I want, however, then I am losing the convenience of using the booking method (LIFO in my case). I tried this:

 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
   Expenses:Fees:BTCMining                                  0.00105853 BTC @ BTC
   Assets:BTC:Coinbase                                     -0.00144853 BTC {}
   Assets:BTC:Jaxx                                             0.00039 BTC {}

But I get an error in bean-check.

I would imagine that this would have the same effect because the cost basis for the lot would be filled in automatically, but I figured disambiguating would help like this:

 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
   Expenses:Fees:BTCMining                                  0.00105853 BTC @ BTC
   Assets:BTC:Coinbase                                     -0.00144853 BTC {USD}
   Assets:BTC:Jaxx                                             0.00039 BTC {USD}



But it books the cost-basis of the BTC in the Jaxx account as 9885.214421538461538461538462 USD :

Yes, it makes sense, see below

 

--> bean-doctor context ledger.beancount 107
Hash:972251de2efc72a4e7f2a2c4654440cb
Location: /home/salotz/tree/personal/studio/projects/index/troubleshooting.general/beancount/issue_000/ledger.beancount:107

------------ Balances before transaction

  Expenses:Fees:BTCMining                                                  

  Assets:BTC:Coinbase               0.01878653 BTC {2661.48 USD, 2017-06-14}

  Assets:BTC:Jaxx                                                          


------------ Transaction

2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"
  Expenses:Fees:BTCMining   0.00105853 BTC @ 0.00000000 BTC           ;                             0 BTC

There are no other legs with BTC, so it fills in a price of zero.
(Note that a legitimate argument could be made as to whether an automatically filled in price of zero should raise an error.)

 
  Assets:BTC:Coinbase      -0.00144853 BTC {2661.48 USD, 2017-06-14}  ;                 -3.8552336244 USD

This gets matched against the inventory, so against the  0.01878653 BTC {2661.48 USD, 2017-06-14} position, and reduces it.
The weight of that posting of -3.8552336244 USD

 
  Assets:BTC:Jaxx           0.00039000 BTC {9885.21 USD, 2017-06-14}  ; 3.855233624400000000000000000 USD

Now this is an augmenting leg, and we must squeeze 3.8552336422 USD 's worth of 0.00039000 BTC, which means they must be worth 3.8552336422 / 0.00039 each, so you get 9885.21. 

Everything is at it should.


Tolerances: BTC=5E-9

------------ Balances after transaction

* Expenses:Fees:BTCMining                                     0.00105853 BTC

* Assets:BTC:Coinbase               0.01733800 BTC {2661.48 USD, 2017-06-14}

* Assets:BTC:Jaxx          0.00039 BTC {9885.214421538461538461538462 USD, 2017-06-14}

Maybe I am mistaken and this is correct but it doesn't seem to me since then if you sold the position in the Jaxx wallet it wouldn't be booked against the original cost-basis that was calculated when the lot was bought.

I don't understand this question.

 

I've attached a minimum working example for a lot of test cases and their results written in the comments. It may not be of much use to you though, but when I don't understand something I tend to go for the enumerative brute force and try to understand the results and compare.

So you start from this:
 2017-06-13 * "Coinbase" "Test buying bitcoin"

  Expenses:Fees:Trading                                          1.99 USD

  Assets:BTC:Coinbase                                      0.01878653 BTC {2661.48 USD}

  Assets:Checking                                              -51.99 USD


The first one looks like it should match, 

;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

;;   Expenses:Fees:BTCMining                                      0.00105853 BTC

;;   Assets:BTC:Coinbase                                         -0.00144853 BTC {}

;;   Assets:BTC:Jaxx                                                 0.00039 BTC


;; RESULT: Bean check error on the directive: no position matches


because there's a single lot in the inventory and it should be able to infer the currency fro that. 
That should be doable (not a bug, but definitely a possible improvement). It doesn't match because of this check:

I'll file a ticket to make this case work:


;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

;;   Expenses:Fees:BTCMining                                      0.00105853 BTC

;;   Assets:BTC:Coinbase                                         -0.00144853 BTC {USD}

;;   Assets:BTC:Jaxx                                                 0.00039 BTC


;; RESULT: bean-check directive error: does not balance as BTCMining leg is not balanced


This is normal; the 2nd posting is in USD, and then you have two augmenting postings in BTC with nothing else to reduce them.
Two currency groups (USD, for the 2nd posting, and BTC for the sum of the 1st and 3rd, each unbalanced).




;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

;;   Expenses:Fees:BTCMining                                      0.00105853 BTC

;;   Assets:BTC:Coinbase                                         -0.00144853 BTC {}

;;   Assets:BTC:Jaxx                                                 0.00039 BTC @ BTC


;; RESULT: bean-check syntax error


That one actually gives me the same error as the first, no position matches against the second posting.


;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

;;   Expenses:Fees:BTCMining                                      0.00105853 BTC

;;   Assets:BTC:Coinbase                                         -0.00144853 BTC {USD}

;;   Assets:BTC:Jaxx                                                 0.00039 BTC @ BTC


;; RESULT: bean-check directive error: does not balance


Same problem as the second (BTC @ BTC should not be allowed, BTW, makes no sense).



;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

;;   Expenses:Fees:BTCMining                                      0.00105853 BTC

;;   Assets:BTC:Coinbase                                         -0.00144853 BTC {}

;;   Assets:BTC:Jaxx                                                 0.00039 BTC @ BTC


;; RESULT: bean-check syntax error


Again, I get a position not matched error, not a syntax error.


;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

;;   Expenses:Fees:BTCMining                                      0.00105853 BTC

;;   Assets:BTC:Coinbase                                         -0.00144853 BTC {USD}

;;   Assets:BTC:Jaxx                                                 0.00039 BTC @ BTC


;; RESULT: bean-check directive error: doesn't balance


Same as the second case, you're correctly matching against the inventory, but the currency groups aren't in balance



;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

;;   Expenses:Fees:BTCMining                                      0.00105853 BTC @ USD

;;   Assets:BTC:Coinbase                                         -0.00144853 BTC {}

;;   Assets:BTC:Jaxx                                                 0.00039 BTC @ BTC


;; RESULT: no error. Books no cost-basis BTC to the Jaxx wallet. Books BTC to expenses


That's expected. You /always/ have to provide the cost basis explicitly on an augmenting leg, unless it's possible to interpolate it because it's the only missing number. Your comment hints that you might think the cost basis numbers somehow translate between postings... they don't. The total cost basis is used to balance with the other legs, but the per-unit cost is LOST in this balancing.
Here the first two legs are interpolated - the second one is first matched against the inventory contents (interestingly enough, this works despite the absence of the USD disambiguation, I have to investigate), the first one has the corresponding price filled in. The third one is alone in BTC and is interpolated to a price of 0 (again, it's debatable whether this should generate an error, I'm starting to think it should).


;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

;;   Expenses:Fees:BTCMining                                      0.00105853 BTC @ USD

;;   Assets:BTC:Coinbase                                         -0.00144853 BTC {USD}

;;   Assets:BTC:Jaxx                                                 0.00039 BTC @ BTC


;; RESULT: no error. Books no cost-basis BTC to the Jaxx wallet. Books BTC to expenses


Same



;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

;;   Expenses:Fees:BTCMining                                  0.00105853 BTC @ USD

;;   Assets:BTC:Coinbase                                     -0.00144853 BTC {}

;;   Assets:BTC:Jaxx                                             0.00039 BTC {}


;; RESULT: bean-check error


The third posting's currency is impossible to categorize. What are the units supposed to be? USD? EUR? JPY? Remember there's no constraint in an account that there ought to be a single currency, or even a single cost currency for the same currency. Maybe I could add that further constraint to an account to make the interpolation more powerful, but it's not like that now, accounts can contain a mish-mash of different things (see the one_commodity plugin).


;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

;;   Expenses:Fees:BTCMining                                  0.00105853 BTC @ USD

;;   Assets:BTC:Coinbase                                     -0.00144853 BTC {USD}

;;   Assets:BTC:Jaxx                                             0.00039 BTC {}


;; RESULT: bean-check directive error: too many missing numbers for currency group USD


Normal. But this should have yielded the same error as the preceding case but somehow it managed to infer the third leg was USD too and we have two numbers to fill-in  / interpolate (on the first leg, and the third one). Not possible.



;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

;;   Expenses:Fees:BTCMining                                  0.00105853 BTC @ BTC

;;   Assets:BTC:Coinbase                                     -0.00144853 BTC {USD}

;;   Assets:BTC:Jaxx                                             0.00039 BTC {}


;; RESULT: bean-check error


Same


;; 2017-06-14 * "Transfer" "Transfer funds to Jaxx wallet"

;;   Expenses:Fees:BTCMining                                  0.00105853 BTC @ BTC

;;   Assets:BTC:Coinbase                                     -0.00144853 BTC {USD}

;;   Assets:BTC:Jaxx                                             0.00039 BTC {USD}


;; RESULT: no error. Books no cost basis to BTCMining, books correct amount to Jaxx

;; but with a cost-basis of {9885.214421538461538461538462 USD}


If you write no {} there will never be any cost basis... on an augmenting leg if you want cost basis you need to provide it explicitly.
I can probably stop here, I think you'll have an eureka moment just now.




My conclusions are that in a single transaction directive it is not possible to automatically (i.e. not specify the position to reduce against) split an inventory reduction into an expense and an asset transfer and keep the original cost-basis.

On an augmenting posting held at cost (e.g., adding a positive number of units of a currency with a {} spec), you always need to either provide an explicit cost basis for it, or that being the only number missing in its currency group, in which case it can be interpolated. 

Per-unit cost basis numbers are /never/ transferred between postings. Only the total is used to balance the postings within each currency group.


 

I tried splitting it into two transactions and this seems to work swimmingly, so this is the way I will do it for now until the booking capabilities are more advanced.

I really appreciate your responses.

Sorry for the delays, I'm currently traveling and working - in my real job - at the same time.


 

~Sam

To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/0a916715-69ab-4337-b327-c256aa3e1f3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/Qvbcq-Sk5NY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.



--

--
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 beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

Samuel Lotz

unread,
Aug 14, 2018, 10:20:44 AM8/14/18
to bean...@googlegroups.com
Sorry for the delays, I'm currently traveling and working - in my real job - at the same time.

Martin, I'm frankly astonished by the quality, extent, and speed to which you are responding to posts from a non-developer newbish user. I appreciate it and it will take me some time to digest your answer fully, but honestly I feel like I should be paying you for professional support. Hopefully I can find a way to contribute back someday.

The third posting's currency is impossible to categorize. What are the units supposed to be? USD? EUR? JPY? Remember there's no constraint in an account that there ought to be a single currency, or even a single cost currency for the same currency. Maybe I could add that further constraint to an account to make the interpolation more powerful, but it's not like that now, accounts can contain a mish-mash of different things (see the one_commodity plugin).

Again I am probably not understanding fully, but if you are using an automatic booking strategy then it could just reduce the next things in the queue/stack whatever they are and just pass them to the other account as long as the constraints on the other account allow for it. This is actually what I would want (unless someone can tell me that is a bad idea). For example if I have an inventory of BTC with both USD and EUR cost-bases and I want transfer them to another wallet (asset account) I don't care what the units of the costs are in. I will have to deal with currency conversion at some point if I sell, but hopefully I can just defer that problem. Is this what the "NONE" booking strategy does?

As for constraints on the accounts, I think that is a great idea. Can't you already enforce valid commodities for an account already without the plugin? E.g.:

  2018-08-14 open Assets:BTC:Wallet BTC

Constraining the cost currencies could be useful too, it might look something like:

  2018-08-14 open Assets:BTC:Wallet BTC {USD,ETH}

I'll get you the details of what version I am running etc. to figure out why we have differences in the source of errors.

Best,
~Sam


~Sam

To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscribe@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/0a916715-69ab-4337-b327-c256aa3e1f3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/Qvbcq-Sk5NY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+unsubscribe@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.



--

--
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 beancount+unsubscribe@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/Qvbcq-Sk5NY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+unsubscribe@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

Martin Blais

unread,
Aug 15, 2018, 10:24:11 PM8/15/18
to Beancount
On Tue, Aug 14, 2018 at 10:21 AM Samuel Lotz <samue...@gmail.com> wrote:
Sorry for the delays, I'm currently traveling and working - in my real job - at the same time.

Martin, I'm frankly astonished by the quality, extent, and speed to which you are responding to posts from a non-developer newbish user. I appreciate it and it will take me some time to digest your answer fully, but honestly I feel like I should be paying you for professional support. Hopefully I can find a way to contribute back someday.

The third posting's currency is impossible to categorize. What are the units supposed to be? USD? EUR? JPY? Remember there's no constraint in an account that there ought to be a single currency, or even a single cost currency for the same currency. Maybe I could add that further constraint to an account to make the interpolation more powerful, but it's not like that now, accounts can contain a mish-mash of different things (see the one_commodity plugin).

Again I am probably not understanding fully, but if you are using an automatic booking strategy then it could just reduce the next things in the queue/stack whatever they are

It does that.

 
and just pass them to the other account as long as the constraints on the other account allow for it.

It does not do that.
This isn't even a common use case AFAIK.

 
This is actually what I would want (unless someone can tell me that is a bad idea).

In most normal usage reductions correspond to a sale, in which case the other side is proceeds + income (profit/loss) + commissions, etc.
Some of the time it's a cost basis adjustment: you reduce and on the other side augment with a different cost basis - in this case you /want/ a different basis.
It's pretty rare that one leg reduces and the other one adds with the same cost basis.

I think what's going on is that BTC usage is offering a new challenge to accounting systems: on the one hand, because it's a speculative asset, its users want to track the cost basis of the units they hold (treating it as an investment (though it's not one)), but at the same time they want to be able to sell tiny slivers of it every time they carry out an expense (treating it as a currency), and easily make these frequent sales as well. None of the systems is particularly well suited for this usage pattern, and Beancount hasn't evolved the features to make this easy.

I'm of two minds about this: on the one hand I like the challenge of supporting these usage patterns, especially if it could be designed by adding an innocuous and otherwise harmless capabilities to the interpolation / booking mechanism in Beancount (this is in line with the spirit with which the interpolation is designed), but on the other hand I also don't care much for BTC - my personal view is that it's a fad - and in the little time I have left to do work on this I've preferred to focus on adding features for (real) investing, such as computing and reporting returns accurately including dividends and time-weighted values, and de-aggregated reporting of basket / ETFs holdings, integration with google sheets for intraday reporting and planning portfolio strategies, and much more that's not all in the public project source. Beancount is, in some sense, in a semi-maintenance mode, new feature development occurs in brief spurts and otherwise being fairly conservative about not breaking things. I accept patches, but they must be well-covered with tests in order to avoid breakage--I really care to keep this in full working state, as I and others use it frequently and rely on it, breakage is really super disruptive--and ideally well isolated code (plugins are ideal). Despite this, I'd be interested to hear what BTC users think would be an ideal type of input from Beancount, and we could entertain ideas for modifications that could support this better eventually.

One way to do this kind of tracking better in the meantime is to treat your BTC like an investment, and otherwise always keep a small stash of converted currency amount to spend in the regular way, in a sense aggregating the spending in order to have less conversions. Don't spend the coins directly (that's probably not an option if you like to think of BTC as a currency). Or go the other route: treat it like a currency and forego the cost basis tracking entirely (I'm not sure that's really an option TBH, the government probably requires it and given the wild price variations you'd want to know what the real value is).

Another idea that is low-touch / easily integrated is to build a plugin to help you write less and automate some of the data entry. You could create a plugin that fills in some of the missing information, though there are limitations.

Or better: perhaps start using it for tracking everything else in your finances and after some number of months when you have a lot of experience with representing regular stuff, maybe that would be a better time to revisit all the challenges that spending BTC units held at cost presents. People often get hung up on particular scenarios, and I always focus on the long term: get your setup working, get into a regular routine of importing the data in your most important accounts; it's most important to have a clear high-level picture of your assets and expenses and prioritize that over the minute details.


 
For example if I have an inventory of BTC with both USD and EUR cost-bases and I want transfer them to another wallet (asset account) I don't care what the units of the costs are in. I will have to deal with currency conversion at some point if I sell, but hopefully I can just defer that problem. Is this what the "NONE" booking strategy does?

No. 
"NONE" simply disables the requirement that inventory reductions are matched to existing positions.
It's the most loose booking method, which can result in inventories containing a mix of positive and negative units of the same currency (at various cost bases).
It's essentially unconstrained.
Try not to use it; it's a cop-out to support pre-tax / retirement accounts, where cost basis is mostly ignored (until there is a distribution) and some transactions occur off cost basis (e.g. fees taken at market rate by reducing existing positions).


As for constraints on the accounts, I think that is a great idea. Can't you already enforce valid commodities for an account already without the plugin? E.g.:

  2018-08-14 open Assets:BTC:Wallet BTC

Constraining the cost currencies could be useful too, it might look something like:

  2018-08-14 open Assets:BTC:Wallet BTC {USD,ETH}

You got the idea.
Enforcing a constraint like this is easy; I was referring more to the idea of using the fact that there is a constraint and feed that into the interpolation code to help it infer more and let you get away with writing less.


I'll get you the details of what version I am running etc. to figure out why we have differences in the source of errors.

Please, though it would be easier for me if you upgraded and confirmed the output is similar to mine.
 

Best,
~Sam


~Sam

To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/0a916715-69ab-4337-b327-c256aa3e1f3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/Qvbcq-Sk5NY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.



--

--
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 beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Beancount" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beancount/Qvbcq-Sk5NY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.



--

--
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 beancount+...@googlegroups.com.

To post to this group, send email to bean...@googlegroups.com.

Martin Blais

unread,
Aug 15, 2018, 10:48:43 PM8/15/18
to Martin Blais, Beancount
There's also this, which might be useful in thinking about prototyping something:
https://bitbucket.org/blais/beancount/src/tip/beancount/plugins/book_conversions.py

It was more of an experiment than anything else.
Search for book_conversions.py on the mailing-list for context.



Best,
~Sam

To post to this group, send email to beancount@googl
Reply all
Reply to author
Forward
0 new messages