Loosing existing entries when I import with OFX

[David Carlson]

On 11/4/2012 4:19 PM, kotareclaire wrote:
> hello
>
> I am a new user to GNU so thanks for bearing with me. 
>  
> I am importing my bank files with OFX however when I do I loose entries that
> were already there (it seems to be random and from the last week of entries)
> meaning that I have to go back and check each date to see where the missing
> ones are and re-enter them - all defeating the purpose of importing really!
>
> I was told to try overlapping the dates (so if I have already imported say
> to 1/2/12 then start with this date on my next import rather than 2/2/12)
> but same thing happens.
>
> Anyone able to give me advice on how to import so that this doesn't happen?
>
> Many thanks
> Claire
>
>
>
> --
> View this message in context: http://gnucash.1415818.n4.nabble.com/Loosing-existing-entries-when-I-import-with-OFX-tp4657744.html
> Sent from the GnuCash - User mailing list archive at Nabble.com.
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>
Claire,

I am a fellow user, not a developer, but since there has not been a
response yet, I'll try to give you an idea or two.

The OFX importer assistant is very intimidating to new users and
experienced users alike.  It is not likely to actually lose data, but if
it is allowed to run without supervision it can have undesired results.

1.  While you are importing a file, if any red lines appear, those
transactions will not be imported.  They must be changed somehow to be
yellow or green.  This is important but not very intuitive.  For some
reason, I get a lot of those.  Usually purchases that my wife made in
her company cafeteria.
2.  Sometimes the transaction matching algorithm will match imported
transactions incorrectly to the wrong existing transaction.  It is
crucial to check every green transaction that is matching to an existing
transaction that the match is correct.  It can match to to a similar
transaction on a different date or same or similar value to a different
payee.
3.  There is no method to keep track of which transactions you have
checked, so you need to develop your own method of working down the page
and remembering which ones you have checked, or even which one you are
checking now.
4.  The only help available is what you see while you are in the
process.  Carefully read the help that you find while you are there.
5.  I often set it to consider a transaction as a new one without any
account assignment even if it should match an existing transaction or be
assigned to a known account, just to defer the decision to be a register
edit instead of an import edit.  These are yellow.  It will give a
default account assignment of "Imbalance - USD" or whatever your default
currency is.  That is easy to find later and correct.
6.  When it tries to predict an account assignment, it will often get it
wrong.  For me the most common errors are to assign gas purchases to
"Dining" or restaurant purchases to "Auto:Fuel".
7.  It is designed to use the Unique transaction identifier that the
bank should be assigning to each transaction as a tool to avoid
duplication if a transaction is imported twice.  That works fairly well
to prevent duplication from overlapping import date ranges, but
sometimes it prevents an error correction of an incorrect match as
described in my comment 2.  That can be very frustrating to discover and
fix.
8.  If your bank creates files with very long descriptions like my bank
does, some of the information abut what the importer proposes to do with
that transaction may disappear off the right side of the window, no
matter how big you make it or how fine your screen resolution is.  You
can shrink the columns by grabbing the vertical lines in the header and
moving them with your mouse.  I also manipulate the scroll bar and
window size and position on the screen to help me remember which
transactions I have checked or to see the existing transaction that it
should be matching to.

Sincerely,

David C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xDC7C8BF3.asc
Type: application/pgp-keys
Size: 1729 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-user/attachments/20121105/e155b9f8/attachment.bin>