QIF import *and* save/load trouble
> Hendrik Boom <[EMAIL PROTECTED]> writes: > > However, transactions which in Quicken had been reconciled in only > > one account show up as reconciled in both accounts. This is wrong, > > but I can probably track then down by hand and hand-edit them. > > That's definitely a bug... I wasn't thinking straight when I added > the reconcile handling. It looks as if tracking them down and hand-editing won't be very useful -- as described below, reconciliation status does not appear to be conserved during save-restore. Just to be clear, I'm running version 1.3.3, downloaded as gnucash-1.3.3.tar.gz and compiled under SuSE Linux. No patches have been applied. > > You mentioned that Opening Balance transactions are still duplicated? > Can you explain the situation before and after the import wrt > Opening Balance? Before the imports, there is *nothing* in the register. After, there are two Opening Balance transactions: 7/31/1992Opening Balance chequing n 13,433.91-17,475.43 7/31/1992Opening Balance chequing n-13,433.91 -17,475.43 And here's an extrace from the .qif file: ^ D7/26/92 T-1,110.12 CX N221 PScotiabank Visa (prof) ^ D7/31/92 T13,433.91 CX POpening Balance L[Checking] ^ D8/ 2/92 T-400.00 CX PCash, Royal Bank ^ The opening balance, by the way, is *not* the first transaction in the account. There is, however, another entry ^ D12/ 1/92 T-107.36 CX POpening Balance Adjustment Ladjustment ^ which I must have put in by hand for some reason some time. But it's probably not relevant, and show up properly, just once, in ther register. I'm also a little puzzled by the 'R' column. Last night I had both reconciled and nonreconciled entries. After saving last night and reloading this morning, they have all turned into "n"'s. (Including the incorrect 'r' entries I mentioned in my previous letter. Also, jump no longer works to get to the other end of transfers. The UI accepts the menu item, the menu disappears, and then nothing noticable happens. It looks as if something has gone wrong during save-restore. > > I'm actually treating an Opening Balance transaction as a real > transaction from an Equity account (by default) into the target. Some > programs uses the OB as just a trick to get an account name in the > file, and it's a transfer from the account to itself. Literally > interpreting this results in a zero opening balance. My opening balance entry is there to establish an opening balance. 'Jump" gets me nowhere from either 'Opening Balance' line. However (surprise), from 'Opening Balance Adjustment', 'Jump' *does* get me to the account for the 'adjustment' category. I tried a few other transactions. It looks as if jump works to and from accounts created from Quicken categories, but not to accounts created from Quicken accounts. This behaviour is different from that before the save/restore. > > Do banks put Opening Balance transactions in incremental downloads > just to identify the account? If so, I'll end up putting multiple > real transfers of money into the account where they shouldn't be. I don't know about banks. The .qif files I am dealint with were saved by an old DOS version of Quicken on December 31, 1999, just before Y2K. > > b.g. > -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: QIF import *and* save/load trouble
> > The opening balance, by the way, is *not* the first transaction in > > the account. > > Well, there goes another invariant :( > > I had been told that the Opening Balance transaction had to be the > first one in the file if it was an indication of the account name. Maybe mine can no longer be taken as an indication of the account name. > What you're seeing is a transfer from Checking (this file) to Checking > (the L field of the transaction), which means that money is taken out > of Checking and put into Checking. Exactly like the register shows > it. Unfortunately that doesn't capture the information that you want, > which is a real opening balance transaction. > > I'll need to think about what the right thing to do is here. > It is easy to fix by hand after importing. Historical background: When we first started Quicken 8 years ago, we provided an opening balance. Sometime after, we inserted some extra transactions with dates that were actually earlier than the opening balance. Then last December, we exported the whole mess into a .qif file. That's probably how it got to be out of order. It may have been a bug in the ancient Quicken I was using. Do current quickens do the same? Anybody know? > > My opening balance entry is there to establish an opening balance. Or perhaps I should have said: > > My opening balance entry *was* there to establish an opening balance. > ... ... ... > > 'Jump" gets me nowhere from either 'Opening Balance' line. > > That makes sense, because it's a transfer from the account to itself > as I explained above. I'd have expected it to get me from the one 'Opening balance' line to the other. > > Your comments about reconcile information not being preserved across > save/restore are concerning. Let me check into that on this end. This, and the probably related failure of interaccount jumps, are the main issues preventing me from making real use of the current version. > > b.g. > Thanks for the help. I'm still thinking about the user-unterface for importing. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: QIF import *and* save/load trouble
> > This, and the probably related failure of interaccount jumps, are the > main issues preventing me from making real use of the current version. Do jumps fail when the xfer field is not blank? If the xfer field is blank, there is no place to jump to. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: QIF import *and* save/load trouble
Hendrik Boom <[EMAIL PROTECTED]> writes: > 7/31/1992Opening Balance chequing n 13,433.91 -17,475.43 > 7/31/1992Opening Balance chequing n-13,433.91 -17,475.43 > > And here's an extrace from the .qif file: > > ^ > D7/26/92 > T-1,110.12 > CX > N221 > PScotiabank Visa (prof) > ^ > D7/31/92 > T13,433.91 > CX > POpening Balance > L[Checking] > ^ > D8/ 2/92 > T-400.00 > CX > PCash, Royal Bank > ^ > The opening balance, by the way, is *not* the first transaction in > the account. Well, there goes another invariant :( I had been told that the Opening Balance transaction had to be the first one in the file if it was an indication of the account name. What you're seeing is a transfer from Checking (this file) to Checking (the L field of the transaction), which means that money is taken out of Checking and put into Checking. Exactly like the register shows it. Unfortunately that doesn't capture the information that you want, which is a real opening balance transaction. I'll need to think about what the right thing to do is here. > My opening balance entry is there to establish an opening balance. Unfortunately, that's not what the transaction literally says. We have to know to treat Opening Balance transactions differently than normal transactions, but we have to make sure that not just any old transaction that happens to have the string "Opening Balance" as a payee gets treated specially. I can envision legitimate "normal" transactions where this would do the Wrong Thing. For example, a transfer of money from a checking account to a new IRA. The transaction is in checking.qif, the payee is "Opening Balance", the amount is $2000, and the L field is [New IRA]. This means take $2000 from Checking and put it in New IRA. However, if we noticed the payee was "Opening Balance" and wanted to treat it as an Opening Balance record, it would mean that the file checking.qif described the account New IRA, that the transaction was a transfer of $2000 from "Retained Earnings" to New IRA, with the balance of Checking unaffected! That's not what you want to happen at all, and it's why Quicken and MS Money supposedly only put Opening Balance transactions as the very first transaction in a file. > 'Jump" gets me nowhere from either 'Opening Balance' line. That makes sense, because it's a transfer from the account to itself as I explained above. Your comments about reconcile information not being preserved across save/restore are concerning. Let me check into that on this end. b.g. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: QIF import *and* save/load trouble
Bill Gribble <[EMAIL PROTECTED]> writes: > I had been told that the Opening Balance transaction had to be the > first one in the file if it was an indication of the account name. Unfortunately you can't count on that. The "Opening Balance" transaction in quicken, way back when I was using it, was just put there during the process of creating the account, but the date used is just the date you create the account. If you're just starting up, you could easily have bills, visa payments, etc. that you enter shortly thereafter that have dates preceeding the opening transaction. I had this happen several times back then. FWIW -- Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: QIF import *and* save/load trouble
Rob Browning <[EMAIL PROTECTED]> writes: > Unfortunately you can't count on that. The "Opening Balance" > transaction in quicken, way back when I was using it, was just put > there during the process of creating the account, but the date used is > just the date you create the account. I don't mean the date of the transaction, I mean the position in the file. This is the convention adopted by MS Money in their QIF exports. There is a reason that it has to be the first transaction in the file: if it's not, there's no unambiguous interpretation of what it means. The MS Money-style Opening Balance transaction is really a wierd bird; it's not just a deposit into the account with the payee being Opening Balance. That would be OK and it wouldn't matter where in the file it was. The problem is that these "special" Opening Balance transactions are nonsense transactions, and have to be treated specially if they are to do the right thing. Syntactically, it's a transfer from Account X into Account X in some amount. But obviously that's meaningless; transferring money from X to X doesn't change the balance of X at all. If you relax the constraint that the special opening balance transactions are the first one in the file, you run the real risk of completely misinterpreting legitimate transfer transactions whose payee happens to be "Opening Balance". I have a couple of these in my personal QIF files imported from a program that didn't even know about the "special" opening balance trick. Normal transfers look just like the "special" opening balance transactions, and if I had a rule that would have gotten Hendrik's case correct, it would have gotten mine completely wrong. I'm not totally sure there's not a way around this, and I'm thinking about it. Any relaxation of the first-position rule will have to have pretty strong heuristic support to not make heinous mistakes, and I'm not sure what those heuristics would be. Bill Gribble -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: QIF import *and* save/load trouble
Hendrik Boom <[EMAIL PROTECTED]> writes: > What is the proper behaviour here? Is 'r' a proper reconciliation code? > Should a different one appear in the accounting file? As far as I can tell, 'r' is used by the reconcile dialog window during its reconciliation process. It was a mistake to use it in the Quicken importing process. This is fixed in the patch I sent in this morning. Thanks, Bill Gribble -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
