Hi Alen,

Here's the plugin that does something along these lines, 
from tariochbctools: 
https://github.com/tarioch/beancounttools/blob/master/src/tariochbctools/plugins/generate_base_ccy_prices.py
You may want to enable it multiple times for a few base currencies.
On a high level it solves the conversion issues for me. I haven't looked in 
detail into things like precision, it just gives reasonable results. If 
precision is a concern, then directly fetching the prices probably would 
work the best.

On Friday, September 5, 2025 at 5:51:38 PM UTC Alen Šiljak wrote:

> Interesting discussion. Yes, the problem is always the same.
> From what I remember, Ledger creates a graph of currencies,  then, when 
> required, finds the shortest path between the two. Don't remember now which 
> algorithm is used for path-finding.
> Also, as Martin commented in that thread, I think a runtime 
> search/conversion would be a better option than creating gazillions of 
> prices with a very high likelihood of not being used at all.
>
> Correction regarding the implicit_prices. Only the pairs with direct 
> prices are converted. So, remains an open issue.
> On Friday, 5 September 2025 at 7:22:57 pm UTC+2 [email protected] wrote:
>
>> On 05/09/25 19:09, 'Alen Šiljak' via Beancount wrote: 
>> > 
>> > 
>> > On Friday, 5 September 2025 at 6:50:47 pm UTC+2 [email protected] 
>> wrote: 
>> > 
>> > This is by design. 
>> > 
>> > 
>> > Thanks for the tip. I understand the concern there and the desire to 
>> > keep the core engine exact. But, the practical use cries for something 
>> > that is a bit more convenient. 
>> > 
>> > For example, I have BAM, which is pegged to EUR by constitution, and I 
>> > have last week's EUR/USD rate because for me that's good enough. Based 
>> > on this data, it certainly is possible to find a simple way BAM -> EUR 
>> - 
>> > > USD, to express any report in any of these currencies. If there was a 
>> > HUF involved, and it included rates to EUR and USD, there would be 
>> > multiple way to calculate. 
>> > Taking the latest, or the first occurrence produces some result. If it 
>> > was possible to see and understand the chain, that would help in some 
>> > odd case. But once a user understand the principle and has correct 
>> > records, this approach produces a very practical result - it uses last- 
>> > known exchange rates to perform rate calculations. 
>> > This is certainly something that a middleware (a plugin?) should be 
>> able 
>> > to do. I was looking already for an existing one but was unable to find 
>> > anything. Hope I find something before going down the rabbit hole of 
>> > writing one from scratch. 
>>
>> Here https://github.com/beancount/beancount/issues/255 there are more 
>> details. There is also a link to code in beancount that computes the 
>> transitive prices 
>>
>>
>> https://github.com/beancount/beancount/blob/v2/beancount/core/prices.py#L138 
>>
>> If someone has a good idea about how to expose that I'd be happy to add 
>> it to beanquery. 
>>
>> Cheers, 
>> Dan 
>>
>>

-- 
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 visit 
https://groups.google.com/d/msgid/beancount/a6f693f7-e9cd-47e0-9171-4f01954cfd8fn%40googlegroups.com.

Reply via email to