I think it would be reasonable to create a function like that and insert it into the environment of a custom beanquery you build for yourself, or perhaps just make a script.
On Thu, Aug 29, 2024, 18:04 DK <[email protected]> wrote: > Thanks, the 10.00 fixed the rounding issue. > > In regard to the main issue. So I already use implicit_prices, but I > wasn't aware of unique_prices. It indeed helped me identify some bugs > caused by the import from GnuCash (or should I say, by GnuCash itself), > where I'd have transaction like > > ``` > 2024-01-01 txn "Something" > Account1 10 EUR @@ 10 USD > Account2 10 EUR > ``` > > So the conversion is not needed. I removed these, and now flipping the > initial transaction order, works correctly. I can't live with unique_prices > on all the time, due to the fact that in real life, market prices are not > unique per day (in fact, I had two ESPP batches that I sold on the same > day, but one was sold at 313 USD while the other at 313.5 USD, hence > unique_prices was complaining about it). But it, nevertheless, helpful to > turn it on once in a while in order to identify bugs like this. > > This brings me, however, to another question. I conduct business in > various currencies, but I have to file my tax reports in EUR. For some > transaction, like the one above, I have explicit conversion rate. I bought > a service for 10 USD, but my bank took 9.32 EUR based on their conversion > rate. Hence, I'm obligated to report a loss of 9.32 EUR. I don't want the > convert function to go and look at the closes rate on that date, I would > like to have a function that converts the cost based on the price attached > to a transaction, if there is one. If there is none, then I need to use ECB > rate for that day in my reports. It would have been nice to have a convert > function like that. On the other hand, maybe it's not the intended purpose > of beancount, and instead I should get the original values to a python > script and process them myself in the desired output for the tax > authorities. > > Thanks for help! > > On Wednesday, August 28, 2024 at 2:09:06 PM UTC+2 [email protected] wrote: > >> On Wednesday, August 28, 2024 at 9:06:04 AM UTC+2 DK wrote: >> >> I recently switch to beancount, and I'm trying to set it up for both my >> personal finances, and for my business. >> >> Consider the following transaction: >> >> ``` >> 2024-08-01 txn "Some Service" "" >> invoice: "xxx" >> Assets:Wise:EUR -9.32 EUR @@ 10 USD >> Expenses:MyComp:Operating:Software 10 USD >> Expenses:Misc:USD >> ``` >> I purchased some service from a US company for 10 USD, but my Wise bank >> account was charged with 9.32 EUR (The Expenses:Misc:USD is there because >> apparently this transaction, as is, does not balance and is missing >> 0.00000000000001 USD, or close to that, but that's a different issue). >> >> >> >> I think Martin considers this to be a bug, but you can work around it by >> putting 10.00 instead of 10 >> >> 2024-08-01 txn "Some Service" "" >> invoice: "xxx" >> Assets:Wise:EUR -9.32 EUR @@ 10.00 USD >> Expenses:MyComp:Operating:Software 10.00 USD >> >> check: >> >> >> https://colab.research.google.com/drive/1laDSOEdxMC2b9yo3zX8e-gxyomM5Zuqm?usp=sharing >> >> >> >> >> ``` >> >> Ideally, if I run the report now, I should get the same value, but I >> don't! Instead, I get 10 USD as the value for the position, but the >> converted cost of the position is now *8.46 EUR*, and even though it has >> a price of 0.93 EUR attached to it. >> >> >> This is because the beanquery *convert *function is not using the >> implicit convertion rate of the transaction (10 USD @@ 9.32 EUR), but the >> price, derived from the latest price directive, which you have staying >> elsewhere. >> It kind of makes sense, because when converting from one currency to >> another you want to use an official rate, not the one used by a >> specific merchant for a specific purchase. >> you can use the implicit_prices >> <https://github.com/beancount/beancount/blob/master/beancount/plugins/implicit_prices.py>plugin >> though. >> >> """This plugin synthesizes Price directives for all Postings with a price >> or >> directive or if it is an augmenting posting, has a cost directive. >> """ >> Even with the implicit_prices >> <https://github.com/beancount/beancount/blob/master/beancount/plugins/implicit_prices.py>plugin >> however, >> you still can get a situation, that on a specific date you may have >> different prices, but the convert function will use only one of it per day. >> >> To hunt such problems, there is a unique_prices.py >> <https://github.com/beancount/beancount/blob/master/beancount/plugins/unique_prices.py> >> plugin >> >> In addition all of them are combined in the pedantic.py >> <https://github.com/beancount/beancount/blob/master/beancount/plugins/pedantic.py> >> plugin >> >> >> >> >> I tried to play with all kinds of parameters in the query, like with date >> or without date, etc, but I still get 8.46 EUR for that transaction as >> converted amount, hence the converted balance is also incorrect. >> >> I don't mind recording the transaction as in the first example, but what >> I'm worried about is that the reports might turn out to be incorrect. I >> randomly caught this transaction, but who knows how many there are/will be. >> >> Am I misunderstanding something? >> >> -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/32d17999-95e8-4613-ac33-370fc20dc41fn%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/32d17999-95e8-4613-ac33-370fc20dc41fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPhLZbo42RefzZ7PSTs1uqHT7yocbU4SGRu6r618RCHRA%40mail.gmail.com.
