GnuCash OFX import not matching accounts of same ID

[Ngewi Fet]

Thanks for the input.

Derek, I will take another look at QIF. Amongst other things I stayed away
from it for lack of standardization, no transaction IDs etc [1]. The issue
of duplicate transactions is handled because the app itself tracks already
exported transactions. So if QIF can fill in the gap here, then it would be
worth a shot.

John, It is indeed easy to forget. I looked through the source but didn't
want to make any changes yet. For one I'm not sure if I'll be breaking what
is expected behaviour in order to suit my case. So I need more information
first and also familiarize myself with the code base, but I'll keep it in
mind. For now, I needed a more immediate fix.

Regards,
Ngewi

[1]:
http://docs.kde.org/stable/en/extragear-office/kmymoney/details.impexp.qifimp.html



On Wed, Sep 4, 2013 at 6:56 PM, John Ralls <jralls at ceridwen.us> wrote:

>
> On Sep 4, 2013, at 9:13 AM, Derek Atkins <derek at ihtfp.com> wrote:
>
> > Hi,
> >
> > On Wed, September 4, 2013 12:01 pm, Ngewi Fet wrote:
> >> On Wed, Sep 4, 2013 at 4:31 PM, Derek Atkins <warlord at mit.edu> wrote:
> >>
> >>> John Ralls <jralls at ceridwen.us> writes:
> >>>
> >>>> On Sep 4, 2013, at 7:04 AM, Derek Atkins <warlord at MIT.EDU> wrote:
> >>>
> >>>
> >>> The importer does map the OFX Account ID to the GNC Account, but it
> does
> >>> not expect the OFX Account ID to be the GNC Account GUID so it doesn't
> >>> shortcut the manual mapping involved.
> >>>
> >>>
> >> Ah, in that case, there is not much I can do then. I thought (and the
> >> general user expectation is) that the GNC OFX importer shortcuts the
> >> mappings.
> >> Meaning that when it sees a transaction with same account ID, it
> >> automatically imports and assigns. If the users have to select the
> account
> >> every time, then it is very cumbersome.
> >>
> >> So if I understand right, the OFX file is treated as coming from one
> >> account and all to go into one account?
> >> The OFX standard has account information for each transaction, however.
> >
> > No, the OFX file is treated as coming from one account and going to one
> or
> > more accounts (each transaction goes from the main OFX-file account to
> > some other account).  However AFAIK the importer does not expect the OFX
> > file to contain GNC Account GUIDs.  The OFX account IDs are treated as
> > opaque strings and the user still needs to manually map the accounts.
> >
> > This is yet another reason QIF is better for your purpose.  If you
> specify
> > a QIF Category of e.g. Expenses:Groceries then the default would be to
> map
> > that to a GNC Account of the same name, so the right thing would happen.
> >
> >
> >>>> Ngewi, the problem may be because some users are trying to use OFX
> >>>> both to obtain transactions from GCfA and from their banks, and if the
> >>>> two don't use the same number, the user must re-associate every
> >>>> time. I'm speculating, but it may be that the importer can store only
> >>>> one OFX mapping per account.
> >>>
> >>> This is true, too. If you are importing OFX for GNC account A from your
> >>> bank and also from the Android App, GnuCash can only store a single OFX
> >>> AccountID map for the account.  So it will overwrite the mapping every
> >>> time you swap.
> >>>
> >>
> >> Yes that would indeed be a problem, especially since the importer does
> not
> >> expect GCfA to have the same account IDs as GC.
> >> So it probably doesn't attempt any matching.
> >>
> >> This means that there is actually no easy way to import transactions
> into
> >> GnuCash (at least full multi-account transactions) from the Android app.
> >> Because even if I implement exporting GnuCash XML, even those cannot be
> >> imported into an existing GC file.
> >> From what I've read of QIF, it is not worth looking at, and OFX is not
> >> cutting it for automatic transaction-to-account mapping.
> >
> > Why do you think QIF is not worth looking at?  What have you read, and
> > where?  If you already know the GNC Account names (which you do if the
> > user does an import into your app) then you can make a QIF file that
> would
> > import extremely easily with very little user intervention back into the
> > main set of accounts.  The only downside of QIF is the lack of
> > duplicate-import detection.  This means if a user tries to import the
> same
> > data multiple times then they would wind up with multiple transactions in
> > their books, unless they manually tell the importer that they are
> > duplicates.
> >
> >> Hmmm...
> >>
> >> Right now I am thinking of implementing GnuCash XML export (in pure
> Java,
> >> not using the C API). Basic features/transactions should be easy to do.
> >> - Upside is that users could open up the file in GC and change stuff
> (and
> >> maybe in the future reload the file in GCfA).
> >> - Downside is that users cannot integrate this directly into their
> >> existing
> >> finance "books". They will have to maintain 2 GC files then.
> >>
> >> It still wouldn't be as seamless as I'd like, but it is a start.
> >> What do you guys think of this?
> >
> > I think it's a horrible idea.  What's the point of maintaining a second
> > set of books?  If you do this there is even LESS of a chance of merging
> > the data, and frankly I wouldn't use an app that wouldn't let me pull my
> > transactions back into my main data file.
> >
> > I'd rather see you implement QIF, or let's come up with a better way to
> > synchronize with the app.
> >
> >> Anyways, thanks for your responses everyone.
> >>
>
> Ngewi,
>
> I agree with Derek that trying to maintain two separate account files isn't
> a good option.
>
> Don't forget that you don't have to live with the defects of the GC
> importers:
> If you want the OFX importer to track two account numbers, or to check if
> an account number matches an account's GUID, fix it so that it does.
>
> Regards,
> John Ralls
>
>