Christopher Browne <[EMAIL PROTECTED]> writes:
> David A Fenyes <[EMAIL PROTECTED]> said:
> > It would be nice if there is an "import" selection in the register window
> > itself, which would place the given account at the top of the "guess"
> > algorithm.
>
> Ah, yes. That is indeed a very good observation.
For single-QIF imports, that seems to be the best guess. However, in
general I think you can do a better job of matching up Quicken
single-entry transactions with each other by a allowing multiple
simultaneous QIF file imports and resolving them into splits before
stuffing them into the engine. In that case, you don't really have
"The QIF File" to match with "The Selected Account".
It's my perception that a large fraction of QIF files use the "Opening
Balance" kludge to specify the account name (true?) and having a
persistent mapping of QIF account names to GNUcash account IDs will
make it easy to guess correctly the first time.
In any case, just knowing what account the transactions are with
respect to doesn't solve all your account-matchup problems; you
still need to match the destination accounts and categories
to gnucash accounts.
I think part of the problem with the current import code is that it's
a 1-step process... you pick a file, and then suddenly there are new
transactions everywhere.
I'm trying to separate this into a multistage process, so you can see
what's going to happen and have a chance to tweak the importing
process before it modifies your gnucash accounts. The first step is
to load and parse multiple QIF files, building a "loaded files" list
in the dialog. For each file, you can specify the account, currency,
radix format, and date format, or allow them to be autodetected
(except the currency... that has to be specified). Autodetection
works quite well now. After loading, if the autodetection doesn't
work (for example, there's no Opening Balance transaction to give the
account name) you can modify any of that stuff before moving on.
In the next tab of the notebook, there's a map of QIF accounts (parsed
from the QIF files you've loaded, either in Account records or from
the "L" fields of transactions) to Gnucash accounts. The initial
mapping is guessed. Right now the guesser is stupid but I'm planning
on something using persistent mappings so once you tell it something
it will get it right in the future. If you don't like the guess,
clicking on that row pops up a GtkTree-based account picker. I
haven't yet included the ability to create a new account in the
account picker, but it shouldn't be hard.
The next tab of the notebook does the same thing, but for QIF
categories. Since there are generally a lot of these, I am thinking
about only displaying categories that are mentioned in one or more
transactions in the file set. I already sort them in the display by
the number of transactions that reference them, which seems to do
pretty much the same thing. Thoughts?
The last tab of the notebook right now is just a text string that
says, "this is an important problem, don't f*** it up." The label on
the tab is "transactions" and the problem is how to do really the
right thing about folding single-entry QIF transactions into splits.
For initial imports (my immediate goal) it's not such a big deal...
in a set of QIF files, you either find a "match" for a transaction
from the other end or you don't, and after performing due diligence in
a mark and sweep you do your best. The problem comes when you are
importing QIF files that you got from your bank that represent a
partial list of transactions, some of which are already in your
records and some which aren't.
My idea is to somehow red-flag fishy transactions (ones that could be
duplicates or half-duplicates), and somehow present these for
inspection. It's going to be somewhat time-consuming and definitely
heuristic to do a full check for duplicates, so my initial feeling was
that I'd make that a "Verify" button on the last dialog page, which
would let you either detect and do something about this case or just
ignore it and click on the big OK that sucks everything into the
engine.
I know this sounds complicated, but it's really not more than I think
is needed to solve the problem reliably. The idea is that once you
have established mappings they will be remembered, so you can just
ignore the back pages of the dialog and it's 3 clicks to import the
file.
Any thoughts?
b.g.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
