Two reasons, actually. The first one is that I get an invoice in USD. And the second one is that I am pedantic, and want to keep a correct record in my ledger.
On Thursday, August 29, 2024 at 8:07:03 PM UTC+2 [email protected] wrote: > I think I understand what you need technically, but I don't understand why > you need it practically. > > > If you buy something in EU, using EU-issued card, you will get a statement > in EUR and in this case why do you bother at all about the fact, that > declaration price of the merchant was 10 USD ? > What is the value of this information about 10 USD? > > In another words why do you write like this, > > 2024-08-01 txn "Some Service" "" > invoice: "xxx" > Assets:Wise:EUR -9.32 EUR @@ 10.00 USD > Expenses:MyComp:Operating:Software 10.00 USD > > > instead of like this: > > 2024-08-01 txn "Some Service" "" > invoice: "xxx" > Assets:Wise:EUR -9.32 EUR > Expenses:MyComp:Operating:Software > note: "Declaration price was 10 USD" > > Another thing is that if you would buy it in USD using USD credit card, > then you would get a statement in USD, but then beanquery would just do > exactly what you need, provided you put ECB exchange rate in your ledger > > > On Thursday, August 29, 2024 at 7:04:57 PM UTC+2 DK 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/adc3b6d7-b3fa-47ba-aeb0-b74f556aaf38n%40googlegroups.com.
