Gnucash 1.8 schedule, ofx and generic import infrastructure

[Chris Lyttle]

On Wed, 2002-11-20 at 10:45, Benoit Gr=E9goire wrote:
>=20
> It would also need to add:
> -Destination account autoselection (auto-split creation) as part of the=
=20
> transaction matching (There is no choice but to put it on the same page,=
=20
> there are plenty of examples where two successive transactions will need =
a=20
> different match) .

I think this is probably not a good way to go from a user perspective.
It would be better to ask the user to match the incoming transaction to
a destination account (with an automated pre-selected one there but
changeable) before it moves on to the transaction matching stage. Having
the user confirm the destination account would also give you another
thing for the transaction matcher to match on.
>=20
> Now, I've taken a lot of heat in the past for the event based, "pop in yo=
ur=20
> face" design of the current generic importer.  Derek and Christian want i=
t to=20
> be druid based.  I've spent much energy defending it, but to this day I s=
till=20
> don't have a clear understanding of what kind of Druid would replace it t=
hat=20
> could do OFX, HBCI, QIF and others.

I'd say, having used both your transaction matcher for OFX and the QIF
druid that your design would quite easily fit into a druid. For example,
the current QIF importer has the 'choose account' at a similar stage as
you do and then in later screens moves into transaction matching. I
think your transaction matcher GUI has a better design than the current
QIF import one, but it is similar and would fit into the druid quite
well.

> To be honest, my motivation for GnuCash isn't at an all time high, and I =
no=20
> longer have 20 hours a week to spend on ofx and GnuCash as I had in the l=
ast=20
> 6 months.  Not that I don't like peer review, (on the contrary, I crave=
=20
> feedback, good of bad).  However I have a feeling a that the code I've=20
> written generates much insatisfaction, not all of which is openly express=
ed.=20=20
> Insatisfaction for me, because I took time to write extensive design docs=
=20
> BEFORE I wrote a single line of code, yet feel that now that it is=20
> implemented, it is not fully embraced.  Insatisfaction for longtime GnuCa=
sh=20
> developers, because the API is not in the usual GnuCash "style"  (And alt=
ough=20
> this wasn't said to me openly, neither is my programming style).
>=20
I'm sorry that you feel that people aren't satisfied by what you've
done. From my perspective OFX import is something GnuCash has needed for
quite some time and I think you've done a great job implementing it.
I've only recently had a bank I use make OFX available, but having
listened over the months to the discussions about it I was itching to
try it out (esp the transaction matcher). My comments about your design
will only come from the point of trying to make it easier for people to
use and understand and not because of questions of style.

> But now that we are in feature freeze, I would like everyone to make a li=
st of=20
> what they don't like in the generic import GUI and API, why, and what the=
y=20
> would replace it with.  Much of the conflict over this code was due to pe=
ople=20
> having different understanding and expectations about what this code shou=
ld=20
> do. It is important that we do this now if we are to work together to imp=
rove=20
> this code.
>=20
Having only used it a couple of times, right now I have only one thing
that I feel needs to be tweaked in how you have the transaction matcher
now. You have both an 'OK' and a 'Apply' button and it is not easily
apparent what the difference is between them except one closes the
dialog and one does not. I feel that it would be sufficient to have just
an 'OK' button.

> Also, PLEASE, I need testers to give me feedback on ofx before 1.7.4 even=
 if=20
> everything is fine, especially with investment support which is brand new=
=20
> code.  OFX was broken in 1.7.2 tarball so I got no feedback from that=20
> release.  LibOFX, the transaction matcher and the ofx module all had majo=
r=20
> changes in the last month.
>=20
I will try now that I have OFX files.=20

Chris

--=20
RedHat Certified Engineer #807302549405490.
--------------------------------------------
	|^|
	| |   |^|
	| |^| | |  Life out here is raw=20
	| | |^| |  But we will never stop
	| |_|_| |  We will never quit=20
	| / __> |  cause we are Metallica
	|/ /    |
	\       /
	 |     |
--------------------------------------------