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
> ,,,,,,,,,Assets:Current Assets:Savings USD,Savings
> 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.).
On 01/03/2019 22:26, David Cousens wrote:
> I can feed you what I've done so far with the multiline, double currency
> transaction. My apologies for taking so long. My wife is a poet and I'm the
> publishing company these days. She handed me the latest book of poetry to
> edit and typeset for printing along with a manuscript from another friend
> just after I started on testing the importer.
I know I appear horrible here but I would like to read that poetry.
> I made it back to the importer the day before yesterday. I have presumed the
> multiline import is working for accounts in the same currency but haven't
> actually tested it so far.
It works for me.
> It would have been logical to do that first. I
> have also ignored trading accounts so far either.
Trading accounts and importing are fine for me so long as you are specific.
> I am counting on that
> being largely dealt with if the multicurrency transactions work.
I can see what you're thinking and it isn't going to work, sir.
The round trip doesn't work.
in plain words:
gnc doesn't understand itself;
there are some basics you need to know about munging, essentially gnc is
generous in what it allows to be stored in a file via the UI (I think
this is a mistake as it allows new lines in a file format that depends
on new lines and so on) and it doesn't allow those chars back in.
Now you know the round trip doesn't work, you know you need to fix a gnc
file to make it gnc compatible ... which sounds weird but is true.
> I will continue and check out a multiline import to accounts with the same
> currency with 2 or more splits.
I'm going over your work and I am impressed with your attention to detail.
in 1.4.1 (c) you say "Set date format to d-m-y to match locale" I think
that is a wrong thing to do, it is all about the file and the round trip.
You also raise something that has been puzzling me, in your table under
1.4.1 (d) I don't know what a withdrawal or deposit is relative to.
Surely gnc should understand debits and credits and plus and minus. I
suppose it is possible someone will import tx to a CC or similar
Liability account as the base for their finances but how likely is that?
Don't most people start with "I have" rather than "I'm fucked, I owe so
much I'm going to use gnc to see how bad it is".
gnc people are generally positive, they're taking care of their finances.
> One thing I am not clear on is whether or not the single line mode is meant
> to be able to import a two split transaction when the split target
> currencies are in the same currency without relying on the matcher. I am
> presuming it is.
I don't know.
I can say the importer says it knows about commodities and doesn't.
> My secondary aim is to learn enough to be able to put some documentation
> together for the importer once I have some idea of what aspects are working.
I'll happily help with that.
> Unfortunately I will have another break as I am off to Singapore in 2 weeks.
> I will keep appending to the document and send you updates.
> I will get to testing the import of these transactions either tomorrow
> morning or Thursday. I don't know yet whether it is possible to import them
> in the multiline format with 2 or more splits yet.
Yes, it is possible but you have to be very careful when creating the
> i am working slowly and
> documenting everything i do so the developers have enough data to start
> identifying where the problems are.
I am impressed at your attention to detail, D
I think the problem is that once you've worked everything through in
your beautifully crafted way you're going to reach the same conclusion
At that point you should make a mug of tea, swig a beer or whatever is
appropriate and conclude, the gnc people haven't got it right yet.
> Once I understand it I will update the
> wiki and then get the Help/Guide docs up to date for the next release. I
> suspect the bug fixes might not make it until the next release comes out
OK, the documentation theory works in two ways: the document can say
what happens or the document can say what might happen.
We are free software so we can't do the latter, doing the former doesn't
make sense either as it hasn't been done yet and may never be done.
What do you put in the wiki, Mr David?
> If you are only exporting and importing transactions with 2 splits you
> should be able to get it to work.
I can make it work with many splits but not many currencies or commodities
> I would create a dummy transaction first
> and export it, delete it in the book and then reimport it.
NAUGHTY BOY! you *know* gnc can't do the round trip of export and
import. It doesn't understand itself.
> There is an
> identified bug in the Export Transactions to CSV where transactions cannot
> be exported on the date they are created so it is better to use Export
> Transactions from Active Window to export a dummy transaction. Bob Fewel is
> already working on a fix for this.
buglist ref please
> I normally setup a test datafile to work with while exploring this rather
> than use a real datafile so that other transactions don't complicate life.
If the test file I looked at earlier is an example, it is near perfect,
I can see your thinking, actually, more importantly, I think other
people can see your thinking. I'm not the important person because I'm
looking at another problem that you may not have thought about yet. I
do question documenting in such detail a problem that might change or
not be there in a month or so, D.
I'm more interested in structural stuff at the moment.