Scott Haug <[EMAIL PROTECTED]> writes:
> Warning: this is a really long email. It details my past few weeks
> using gnucash and some ideas/suggestions I've had for it in the
> process. I apologize to those of you who have to pay for your
> internet access by the minute.
(Ditto what Bill said about not apologizing for being helpful.)
> I believe Moneydance actually enters the next highest number of the
> most recent check in the register, but this isn't perfect either,
> since I often postdate checks and I thus end up with checks with
> higher check numbers coming before lower-numbered checks in the
> register.
An alternate would be to record the last check number entered and bump
that. That would require storing non-financial per-account data
across invocations, and guess what... <surprise> we need that for a
lot of other things, so as Dave alluded to later, stay tuned, we'll be
addressing that soon. Then we can decide whether or not using the
most recent number as the base is the right thing. I think it's
likely to be pretty good.
> * It would be nice if autocomplete for the description would also
> enter in the information from the last transaction with that
> description. That's the default behavior in moneydance and quicken,
> and I find it speeds up my data entry considerably. Also, I was
> curious why the autocomplete for the description didn't also pop up
> a window the same way the autocomplete for the account did. That
> way, someone could type in the first char or two, and then use the
> arrow keys to find the exact description they were looking for.
Nice idea, though this could be a pretty long listbox if you've opened
a register on thousands of transactions. Perhapse we could limit it
to the last N descriptions if we added this feature.
> Finally, I can't stress enough how useful a 'repeated/upcoming
> transaction' interface would be. This is the one thing that forces
> me to continue using Moneydance in parallel gnucash.
I hear ya. Bear with us. Implementing this right (at least to the
first approximation) requires the same enhancements that we need to
address things like the check number +/- suggestion I made above.
These enhancements are at the top of the to do list, and recurring
transactions are just after.
> I've never programmed with gnucash before, so it might be over my
> head, but I'm decent with C and did a lot of scheme programming as
> an undergrad.
Sounds like you're fairly well qualified for the job. You might want
to give it a try and feel free to ask questions when you need help.
We can usually either answer them or point you at the M that you need
to RTF.
> Again, I apologize for how long this message has become. If you
> made it this far, I hope some of my suggestions resonated with you.
> I'd love to hear comments on them, even if it's just "this isn't
> something we want for gnucash."
OK. "this isn't somethine we want for gnucash."... Er, um wait,
scratch that, make it "Thanks for the really helpful comments; keep
'em coming."
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
