search

eprbell / rp2

Privacy-focused, free, open-source cryptocurrency tax calculator for multiple countries: it handles multiple coins/exchanges and computes long/short-term capital gains, cost bases, in/out lot relationships/fractioning, and account balances. It supports FIFO, LIFO, HIFO and it outputs in form 8949 format. It has a programmable plugin architecture
https://pypi.org/project/rp2/
Apache License 2.0
256 stars 42 forks source link

Non-zero balances when zero is expected #112

Open gbtorrance opened 2 months ago

gbtorrance commented 2 months ago

In fifo_open_positions.odt in the "Asset" and "Asset - Exchange" tabs I am seeing a few cases where Exchange balances for certain Access should be zero, but they are non-zero by a tiny fraction. For example: 0.00000000003 and 0.00000000011.

In all cases the funds should have been fully transferred out of the particular Exchange (resulting in a zero balance), but this is not reflecting correctly in the open positions. I have checked the numbers in the spreadsheet multiple times, and I'm pretty sure they are correct (i.e. should be zero). It's not a big deal, but as someone who likes things to be precise, it's a little distracting.

Is this an expected situation given imprecision of the underlying number types (either in LibreOffice or Python), or could there be something else going on here?

I'm happy to create a test case to replicate this, but before I do so I just wanted to ask, "Is this normal?" (If it is expected, no worries; feel free to close the ticket.)

Thanks!

eprbell commented 2 months ago

Errors around the tenth decimal position could be due to precision limits (RP2 uses 13 digits of precision, I'm not sure what LibreOffice's limits are). Do you see similar errors in the rp2_full_report.ods file?

gbtorrance commented 2 months ago

Hi. Thanks for the reply and the info.

To your question, yes, the same thing shows in the rp2_full_report.ods file.

Actually, I'm seeing another issue that I think is related to precision. It's resulting in the "Total in-transaction crypto value < total taxable crypto value" error occurring (when I believe there should be none).

In both cases I think the numbers should "zero out" nicely, but they're resulting in either tiny positive exchange balances or tiny negative ones (producing an error).

I've got examples for both in the attached and have added comments to the sheets (in red) for explanation.

Interested in your thoughts. Thanks!

RP2_Test.zip