…Actually, I stand corrected - I read the translation more carefully & this seems not to be related to HIFO sales but to an ordering bug with transfers…which is actually now also affecting me (I was linked here from this thread).
I’m trying to use PP to track crypto transfers & sales, which must be FIFO. Consider these operations:
- Buy 1 unit on a crypto exchange, call it lot E1
- Buy 1 unit in a wallet, W
- Buy another on the same exchange, call it lot E2
- Transfer everything from the exchange to the wallet (2 units)
- Some time later, transfer 1 unit from the wallet back to the exchange. I would expect that it would pull E1 here as it’s oldest.
- Sell 1 on the exchange. I would expect it to be E1.
However, it sold W. This does seem like a pretty impactful bug, as in this case it would lead to incorrect sales order for tax reporting purposes.
Curious, has this been reported as a bug on Github yet? Maybe it would get more visibility from the developer there?
Edit: For a little more context, I’ve been using PP for tracking crypto sales for tax reporting purposes. It’s worked great for the past several years, where I’ve just had one “Crypto” account (regardless of the actual number of wallets/exchanges) - so-called “Universal Accounting.” Starting 1/1/2025 though, you’re no longer allowed to do that in the US (see: here). Instead, you must do FIFO wallet-by-wallet. So I’ve created a separate account for each exchange or wallet, & transfer the assets in PP just as they move in reality. However, this bug means seems to mean that won’t work - it gets out of the correct FIFO order. Pretty big issue honestly - I have no idea how I’ll be able to track things & comply going forward.