Comments (8)
Ok yea that works, I will try that then. Maybe the validation checks if at least one kind of fee is specified. And I dont, I have typically only seen crypto fees.
from rp2.
I added a FAQ about this: https://github.com/eprbell/rp2/blob/main/docs/user_faq.md#how-to-represent-fiat-vs-crypto-transaction-fees.
After some more thinking on this topic, I came to the conclusion that the existing implementation is OK as it is: giving prominence to crypto_fee (non-optional) over fiat_fee (optional) in out-transactions seems correct to me (because we don't know of any exchange that allows fiat fees in out-transacitons). If we discover an exchange that allows fiat fees in out-transactions, then we should make both crypto and fiat fees optional in out-transactions.
from rp2.
This sounds like a case that can be modeled with a fee-only transaction. If you have an out transaction denominated in crypto C1 and you pay fee denominated in C2, you can do this:
- model the C1 out transaction with 0 crypto_fee;
- add a C2 fee-typed out transaction.
- if you like add something in the notes to point out the two transactions are connected
Let me know if this answers your question.
from rp2.
Ok gotcha, what I have been doing is just doing another conversion back to the crypto fee from fiat, which works, but I assume you are then converting the crypto_fee back to fiat in the tax engine. right? Its not a make it or brake it thing for me, its just a nice to have and saves an extra step
from rp2.
Right, so to summarize, here's what you can do in an out-transaction, wrt fees:
- if the fee was paid in the same crypto as the transaction: pass crypto_fee > 0 and no fiat_fee: RP2 populates the fiat_fee internally as spot_price * crypto_fee;
- if the fee was paid in fiat (not in crypto): pass crypto_fee == 0 and fiat_fee >= 0: RP2 uses fiat_fee as passed in;
- if the fee was paid in the same crypto as the transaction, but the exchange reports a fiat_fee value that doesn't match crypto_fee (this happens sometimes on Coinbase): pass crypto_fee >= 0 and fiat_fee >= 0 (it should generate a warning log)
- if the fee was paid in a different crypto than the one the transaction is denominated in: use an additional fee-only transaction (transaction_type="fee"). I don't think this case can be represented with only one out-transaction with a fiat fee, because this would not capture the fact that some of the second crypto has flowed out (which affects accounting for that crypto).
Perhaps this should go in a FAQ, as it's a good question. Let me know if the above makes sense or if you think more clarification is needed.
from rp2.
Ok so sounds like I can add both crypto_fee and fiat_fee to the out table and config and RP2 will know what to do? Also crypto_fee is required while fiat _fee is not it seems
from rp2.
Yes, that would be the third case I listed above: in case of value mismatch, RP2 will use the mismatched fiat_fee in its tax calculation, but will issue a warning.
The crypto_fee is required, because I my thinking when I designed RP2 was that the fee would always be paid in crypto for out-transactions. Do you know of a case of an exchange where out-transaction fees are paid in fiat? In the current implementation this can still be captured using case 2 above, but crypto_fee has to be passed in as 0. Perhaps I can just change the implementation of out-transactions to be similar to in-transactions (both crypto_fee and fiat_fee are optional).
from rp2.
Ok cool sounds good
from rp2.
Related Issues (20)
- Add Support for Denmark
- Add Support for Finland
- Add Support for Norway
- Add Support for Brazil
- Add Support for Argentina
- Add Support for South Africa HOT 2
- Incorrect lot exhaustion in HIFO HOT 2
- Few minor suggestions HOT 1
- Uncertain, but considering making a python wallet reader HOT 1
- Per wallet/exchange Specific Identification (FIFO, LIFO, etc...) Resolution HOT 27
- Exception when executing HOT 3
- Question about "Open Positions by Asset" report HOT 2
- Crypto fee in OUT table HOT 24
- FIFO and exchange/wallet cost-basis calculation HOT 5
- RP2 process runs after "DONE" HOT 5
- Investment Expenses can no longer be used for Deductions HOT 10
- Call for GUI coders: create an intuitive GUI to drive RP2 and DaLI HOT 3
- I can def help HOT 2
- Using Pionex data to Rp2 using dali isn't working. __crypto_sent = unknown HOT 4
- Error total in-transaction crypto value < total taxable crypto value HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rp2.