Josh Sled <[EMAIL PROTECTED]> writes: JS> On Tue, Jun 26, 2001 at 12:21:26AM -0400, Aaron Peromsik wrote: JS> JS> | At work, in completely unrelated software, we often focus on the JS> | number of mouse clicks required to perform common tasks as a measure JS> | of usability. JS> JS> Noted... I'd be interested to see your report on how JS> GnuCash::ScheduledTransactions fares in this study... [ :) ] Well, I don't exactly have a report yet, but my initial reaction was "too many clicks." However based on our subsequent discussion I've gathered most of them will eventually be optional, so hopefully we should be OK when you're finished. JS> When I say "defer the creation of", I'm thinking that a particular SX JS> comes due [utilities bill], but you haven't actually received the bill JS> yet [the DOM is a Saturday, and you'll get the bill on Monday]... so you JS> defer it's creation such that it will keep coming up as 'to-be-created' JS> ea. time you start GnuCash, until you actually have the facilities to JS> create it [the bill, with the correct amount]. I can see that this is something that some people will want. However, for my own use, I think it would take fewer clicks to have the transaction shown in the register already with the initial estimate. When the actual bill shows up I can fix the date and amount and then "enter" the transaction for real. I guess it's partly a philosophical issue... some people want dialogs saying "I'd rather you didn't do anything else until you deal with this bill, unless you'd rather defer it." I'm happier with an entry in the register highlighted in blue so that I remember I have to do something about it, but I don't have the system nagging me with a blocking dialog. JS> As far as I see and understand what you're saying, there's no call to JS> interact with the 's' transactions in the register... they're there until -- JS> as you say -- you actually write the check; at that time they're created, JS> and you fill in the check number and appropriate amount. Right, but I want to do that directly in the register, with a minimum of extra UI. JS> Up until that time, many things might change. You may change the frequency JS> or the parameters of the SX. Instead of going through the books, removing JS> these 's'-status actual transactions, and creating the new ones, I think JS> it makes more sense to not have created them at all. JS> JS> This is not to say that they won't appear in the register... the register JS> should show a user-configurable window of future transactions... but I JS> think they're not marked 's' so much as they have a ' '/null-reconciliation JS> field: they're not [yet] transactions, and they don't exist in the books. Are you saying that the register will have additional functionality for display scheduled transactions that don't exist yet and are not in the database? That sounds like considerable extra work. My gut feeling is that, if you have a field associated with 's' transactions telling which SX it came from, then implementing the process of ripping them out and replacing them when an SX's parameters change will be easier than implementing support for phantom entries in the register. JS> However, this would not be appropriate for you, if you intend to run JS> reports over future transactions... [?]. I *don't* have plans to run reports over *future* transactions, but if the right report came along it could suddenly become useful. However, 's' transactions in the past, where I haven't quite paid yet but maybe should have, really ought to be in reports if I am using reports to decide whether I can afford a new whatever. JS> I'm starting to fear that the creation-policy options will be too JS> cumbersome... I'll code it up and we can see how much is there at the end, JS> and then make the tough decision about which policy to ignore. I'm not sure I follow... are you saying you think we're coming up with too many configurable options relating to creation policy? Dividing them up into things you'd want to do differently per transaction vs global system preferences (per gnucash file) may help a bit. I don't think having too many of the latter kind is a problem since most people will configure those exactly zero or one time(s). JS> I'm thinking multiple roommates... Interesting. JS> I know another user will likely make use of this for his loan repayment, JS> which he seperates out into splits for the interest and principal payments. JS> Once the formulas can contain functions, this becomes auto-calculable; JS> however, I doubt this is a first-cut feature... I expect that a much greater number of users will find this useful than the formula stuff. As evidence, Quicken autocomputes loan payments, but doesn't have the formulaic splits like the ones you describe at a user-editable level. Just something to keep in mind. I know you'll implement the stuff you need first, since that's the name of the open-source game, but if LDP wants to make money off this then they should keep in mind that handling loan payments might be seen as pretty basic missing functionality vs the competition. JS> Ahh... I remember that post... and it did influence my targets for this, JS> though it may not be apparent in the code right now... but there's still JS> plenty left to do. OK, just checking... as you say, it's not obvious yet, but I don't mind that if it's temporary. JS> | What I intend to gain from pre-entering scheduled transactions in the JS> | register is to know what my key accounts' balances are likely to be in JS> [deletia] JS> | transactions there. But I don't think that's the intended meaning of JS> | "double-entry accounting--" I want to do it all in one place. JS> JS> "double-entry accounting"... heh... JS> JS> I hope that the budgeting stuff will ultimately be more useful than the JS> use of scheduled transactions for this, but that's in the future... I've mentioned before that Quicken's budgeting takes way too much work to get any reasonable info out of. No offense, but I don't expect yours to be too much better. It's hard to do the computations without specific data, and yet when you go to make assumptions based on previous data, you're bound to get something wrong that I'll have to fix before your outputs are useful. Fortunately, I think the use of scheduled transactions will be sufficient for my needs. -- Aaron _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
