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.
