[GNC-dev] Transactions vs Splits

cicko alen.siljak at gmx.com
Thu Mar 7 03:53:30 EST 2019


David, that's a very elaborate explanation. I'm sure there will be enough
information once you are through with testing. So far our findings match.
One thing I'd like to note,


David Cousens wrote
> Date,Transaction ID,Number,Description,Notes,Commodity/Currency,Void
> Reason,Action,Memo,Full Account Name,Account Name,Amount With Sym,Amount
> Num.,Reconcile,Reconcile Date,Rate/Price
> 15/11/18,b60da83af9b84334aa2f5e129c23016f,,Transfer with currency
> exchange,,CURRENCY::AUD,,,,Assets:Current Assets:Savings Account,Savings
> Account,$100.00,100.00,n,,1.00
> ,,,,,,,,,Assets:Current Assets:Savings USD,Savings
> USD,-$110.00,-110.00,n,,10/11
> <snip>
> The Price is what should control the currency conversion. 

I find the Price and Amount information redundant, if both are sent. For
example, if they don't match, which one is the relevant one?
If amounts are sent in all splits, it would be better to read the amounts
and calculate the price/rate on import.

I assume your export is from GnuCash so it is good to learn that it exports
the Price element, too. I'll adjust my export to do the same, just in case.

In conclusion, the current state of import would work fine for transactions
in single currency. 

Another issue I had with QIF import was that it was matching accounts by
name, which is not what I wanted. When exporting transactions that use
categories, then expenses in all currencies go to, for example, Dining. QIF
import would always match Dining to Expenses:Dining, which is in EUR, in my
case. So it would always create duplicate accounts after the holidays.
One thing for me to check is if the CSV importer is better in that regard
and will match (or at least remember manually set values) the categories to
the accounts in correct currency (i.e. Expenses:Dining:AUD etc.).



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html


More information about the gnucash-devel mailing list