Re: SX editor bug (?)
On Tue, Jan 29, 2002 at 10:59:58PM -0500, Tim Wunder wrote: | Using gnucash 1.7.0 from cvs dated 1/21/02. | I recently had occasion to change the amount of the SX for my weekly pay (tax | law changes...). The SX has three entries: a debit to Checking, a debit to | Savings and a credit from Inc Sal. When I change the amount of the debit to | checking and thru the rest of the line, I am presented with a empty | register window rather than the next line in the SX (by "empty" I mean that | all entries have disappeared from the window and I'm presented with an empty | register line). If I press and the bring the SX back up into the | editor, the change I made to the Checking debit is accepted, but the rest of | the SX becomes unbalanced (I didn't get to off-set the debit change with a | credit change). This happens regardles of which line I change. If I don't | make a change, I can thru the lines normally. This is related to some recent Query-related changes/deprecations which have occurred ... I've had very limited Gnucash bandwidth recently :(, and have only gotten time today to follow up on this. Hopefully it can be resolved relatively quickly, but I'm not sure... if you need to use CVS for stuff, I suggest reverting to a pre-11/25/01 CVS build [it appears that the critical Query change occurred then]. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: unable to run current CVS [_IO_*/__flockfile, __pthread_waitfor_restart_signal]
On Mon, Dec 31, 2001 at 05:01:45PM -0800, Josh Sled wrote: | I've been unable to run CVS for a few weeks, now ... Switching out from guile-1.3.4 to guile-1.4 seems to have fixed the problem... Unfortunately I believe guile-1.3.4 is what [ximian-]gnome-1.4 wants... At least I can start doing Gnucash development again. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
unable to run current CVS [_IO_*/__flockfile, __pthread_waitfor_restart_signal]
I've been unable to run CVS for a few weeks, now ... The general symptom is... #0 0x400f2966 in __sigsuspend (set=0xbfffe380) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45 #1 0x40d84d61 in __pthread_wait_for_restart_signal (self=0x40d8e460) at pthread.c:969 #2 0x40d86aa3 in __pthread_alt_lock (lock=0x81d8048, self=0x0) at restart.h:34 #3 0x40d82fb6 in __pthread_mutex_lock (mutex=0x81d8038) at mutex.c:120 #4 0x40d85d8b in __flockfile (stream=0x81d7fa0) at lockfile.c:39 #5 0x4013c9c5 in _IO_link_in (fp=0x81d7fa0) at genops.c:108 #6 0x4013c5f9 in _IO_new_file_init (fp=0x81d7fa0) at fileops.c:150 #7 0x401322af in _IO_new_fopen ( filename=0xbfffe590 "/usr/lib/python1.5/site.pyc", mode=0x409780d2 "rb") at iofopen.c:63 ... though frames above #4 change in ea. occurance [frames 0..4 are consistent]. I noticed it first with attempting to load the modular libraries; going from libtool1.4b to libtool-1.4.2 seems to have fixed this. Then, I was getting it on attempting to load /usr/share/pixmaps/gnome-term-tiger.png [gnome_window_icon_init -> ... -> gdk_imlib_load_image] ... removing this file sidesteps that error, which then lets me see the above backtrace, occuring on attempting to load site.pyc [for Guppi init]. Any clues/help? ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Scheduled Transaction Templates
On Sun, Dec 16, 2001 at 01:11:42PM -0500, Tim Wunder wrote: | 1. The variables don't seem to like being blank, or 0. If I have blank | variables, the SX will not complete. If I change then to 0.01, the SX will | complete. It seems logical to me that blank variables would be treated as 0 | and 0 value variables should be acceptable. Maybe I'm missing something... Yes ... you're correct. This is the way it should work; I've added these to the TODO and bugs list. | 2. I can't seem to use ordinary math functions within the variables (+/-). | line items to add together. It wold certainly be convenient to just enter the | line ites separated by '+' and have the variable get calculated. Unless, | again, I'm missing something... That should work fine. There shouldn't be anything wacky about the expression, there ... it doesn't need an '=' at the front or anything. But it could be the case that the variable expression it doesn't get re-eval'd as an expression, but I was pretty sure it did. I'll investigate. | 3. If I press , the cursor should go to the next variable entry block, | but it doesn't. I've gotta hit tab twice. Yeah... there's all sorts of tab-ordering problems in all the various SX parts... I wanted to wait until the UI stabalized until fixing those. | 4. Where variables get most cumbersome is when entering a credit card SX. | I've tried to list all potential accounts that my Credit Card payment is | going to need to update. But, invariably, something special will come up. I'm confused about your example... if the CC payment is scheduled, why does it not come from one place [where you usuallly pay the CC from]? And if it does change, then ... well ... you'll just have to manually deal with that ea. month/period, I guess. | It | sure would be nice to have a screen where I can finalize the transaction, add | accounts/amounts prior to posting it. As it stands now, that's done from | within the Checking account, which I suppose is OK. But it sure would be | nicer if it could be done from within the SX dialog. Yes; once you bind the variables, it will [eventually] re-display the transactions for you to finalize. I haven't done this yet because I want to finish some other UI changes which will make it easier to do that, but haven't gotten around to it, yet [see below]. | 5. I'd like to be able to post an SX even if it's outside the time frame | assigned to it. Say an SX is scheduled to run 7 days prior to a particular | date. I'd like to be able to run it 8, or 10 days prior without bringing up | the SX dialog and editing it. For this, I'd say set it to 10 [max] days and subsequently ignore it until it's time to go... the annoying thing about doing that is that it will keep bringing up the since-last-run druid every time you run GnuCash ... so maybe it'd be nice to be able to go to the SX list and just say 'create this right now'... | BTW, I've finally updated from CVS, so I'm current. Doesn't look like jsled's | gotten to do much with SXs, though. I guess he's fairly busy with other | things. No, I really haven't... and yes, I've been very busy with work and real life... but I hope to return to this stuff w/in the next week or so... | I wish I could lend a hand with coding, but I'm not much of a [deletia] | I might be able to make a little sense out of it. Possibly even contribute The main files are in the engine [src/engine/SchedXaction.[hc] and src/engine/FreqSpec.[hc]], though those haven't changed much. Most of it's actually in the UI, which is src/gnome/dialog-scheduledxaction.[hc] and src/gnome/dialog-sxsincelast.[hc]... There's probably some things [like tab-order] which aren't necessarily coding-related [I think it can all be specified from w/in glade] which you could deal with ... and would be tre-useful. Check out the src/doc/TODO-schedxactions for an idea of what's to be done... | Anyway... I'll continue to work with it and post any suggestions or problems | I might have. Excellent! ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Ledgers, Registers and Sheets Oh My!
On Tue, Nov 27, 2001 at 09:24:41AM -0500, Derek Atkins wrote: | I've been working on an EntryLedger (to manipulate Order Entries), | which looks a lot like the SplitRegister, but different. I'm | wondering how much ELSE I'm going to have to change or re-implement to | get it to work. This really sounds like I might need a LOT of | duplicated code elsewhere, which would seem to be the "wrong" thing. Indeed... and in my code-browsing and talking to dave_p on #gnucash last night, it was apparent that it would be good for the register widget to be able to handle Registers generically instead of just SplitRegisters. I was going to survey the functions which dealt with the SplitRegisters, and get in touch with you to see if we can pull out some interface for what would otherwise be a Register base class. In that example, for instance, that get_blank_split[_vcell] SplitRegister-taking function is probably generic across all registers ... something like "get blank entry vcell" or something... | It would be nice if there were one or two APIs that I could implement | that would give me what I want, instead of having to re-build | everything from the SplitRegister all the way up the the RegWindow and | beyond. You'll get only agreement from me... that would be nice. | Take a look at business/business-ledger/.. for what I've done so far. I will. Cheers... ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Ledgers, Registers and Sheets Oh My!
I've been puzzling out the relationship between the code in
window-register.c [RegWindow, let's say], the GNCLedgerDisplay, the
SplitRegister, the GnucashRegister, the GnucashSheet and the Table...
After talking to dave_p this evening, things are much more clear.
I was especially curious about what constructs like the following [slightly
edited] were all about:
void gnc_register_jump_to_blank (RegWindow *regData)
{
SplitRegister *reg = gnc_ledger_display_get_split_register (regData->ledger);
VirtualCellLocation vcell_loc;
Split *blank;
blank = gnc_split_register_get_blank_split (reg);
if (gnc_split_register_get_split_virt_loc (reg, blank, &vcell_loc))
gnucash_register_goto_virt_cell (regData->reg, vcell_loc);
}
Specifically, it seems like there's two very similar registers at play
['(SplitRegister)reg' and '(GnucashRegister)regData->reg'].
But, as it turns out...
The SplitRegister is, as mentioned, an application-specific
Split-containing-thing editor, which interacts with the Table [a ui-agnostic
tabular editor], which itself is an MVC-patterned thing.
The GnucashRegister is a Gnome-specific UI for that table ... it should
probably be named GnomeTableView, but isn't.
Thus, the call above gets the vcell_loc of the blank_split from the
application-specific SplitRegister, and feeds that to the UI-specific
GnucashRegister [read: GnomeTableView]... thus jumping to the blank split
as per the user's request.
In the course of this, I came up with a .dia file of the relationship
and navigability between these things; a .png export of it is attached.
Please forgive my mangling of UML notation.
...jsled
register_ledger_sheet_oh_my.png
Description: PNG image
Re: Scheduled transaction entry idea
On Sun, Nov 25, 2001 at 09:52:48PM -0500, Tim Wunder wrote: | Further detail on how to make the credit/debit formula a variable would be | helpful. Where can I find that info? Any non-numeric bits in the "credit/debit formula" will become a variable name. Standard/basic math operators are respected as well... so, entering: "foo + ( bar / baz )" ...in a SX template split would bring up a clist entry in the since-last-run dialog, asking for values to bind to the variables so it can evaluate the expression. That's it, for now. I'm not happy/finished with that UI, so once I figure out how I want it to work I can document it a bit better... really, I hope to find a decent UI so that explicit documentation isn't required reading. | all my recurring bills: credit cards, gas, phone, water, etc., each with [deletia] | also have a bar graph on the bottom of the page that shows a real time [deletia] | flow situation will be, if I stay on budget (according to my SX's), or modify | my budget in some way. And I can see, with a great deal of accuracy, my | current cash flow situation. Damn... that's exactly what I want to do. [example snipped] | This is really what I'm after with my SX Template idea. Rather than having to | edit an existing SX and then add a new SX, I'd like to be able to just create | new SX based on an SX Template. | | Does that make sense? Not really... I'm trying to figure out what's not ... configurable ... enough in the current SX setup to allow it to work for you outright: The SX stuff let's you specify: 1. A recurrence frequency [this seems like it's fine] 2. A list of template splits [with variable amounts] It seems like you're editing the SXes to get the amounts right M-t-M ... hopefully knowing about the ad-hoc variables and the since-last-run support for prompting you for their values at entry-creation time should solve that problem. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Scheduled transaction entry idea
On Sun, Nov 25, 2001 at 02:17:33PM -0500, Tim Wunder wrote: | I'd like to see a feature where I can enter a scheduled transation as an | invoice, much like business accounting packages enter AP invoices. For personal finance, while this would be nice, this isn't how it's usually handled. | Say I receive my Gas and Electric bill on November 1st. It's due on November | 20th. I want to be able to quickly enter a scheduled transaction with only | the following data points: | Payee: The Gas and Electric Company | Due Date: November 20th | Amount: Split between Electric and Gas All GNC and the SX stuff currently concerns itself with is paying things ... it doesn't care when you received the bill, or how many days you have it "owed" ... the SX stuff will assist you when the G&E bill is due on the 20th, every month. So you create a G&E SX for the 20th, with the appropriate splits, and then twiddle the creation options [remind, create in advance, &c] until it behaves how you want. If the amount isn't fixed/known, then I'd make the credit/debit formula a variable, and let the since-last-run stuff prompt you for the amount on a monthly basis. | So, I figure, your looking at the creation of a scheduled transaction | template., with the ability to create templates for the various periodic, and | variable, bills you receive. You then can enter an SX from that Template, | something like: Tools-Scheduled Transactions-Create from Template. You're adding a intermediate step [this Template SX stuff] that I don't see as being necessary; the SX defines a recurring Transaction[s], and the template transaction defines a template for what's to-be-created. There's no particular call for a template-SX, which contains Template Transactions. There may be a call for generic Template Transactions [which are not recurring, and are just available to be cookie-cut into the books per the user's demand, but that's a different idea]. | Is this feasible with the makeup of the current SX engine? Not really. It seems more like you want Scheduled/Recurring A/P than a Template SX... and I would handle that differently [i.e., keep the same SX framework, but instead of a Template Transaction, have a Template A/P ... depending on how different Transaction and A/P are. I would hope that the A/P editor is integrated into the SplitLedger that already exists, but I defer to Derek/others about how that should best be done]. I do believe there's an advantage to having A/P for personal finance [I'm thinking budgeting and intra-month funds allocation], but only after the tools to play with that are created... ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: RFC: refactoring window-register as widget-register + containing window
On Thu, Nov 22, 2001 at 08:18:00PM -0800, Chris Lyttle wrote: | My comments on this are purely from an end user point of view. As | someone who is spending a lot of time looking at portions of the GnuCash | interface (while doing docs) this seems like a good time to comment on | some aspects of the UI. I would encourage you also to look at the GNOME | 2.0 HIG http://developer.gnome.org/projects/gup/hig/draft_hig/ and | http://geocities.com/mpt_nz/ig2h.html I want to be clear that I'm focusing here on a refactoring that should change the UI [for the window-register] exactly none. While these comments are quite good, and we should make an effort at some point to respect the HIG, I think that change will necessarily come later... and problably not driven by me. | would be nice if we could either cut the size of the toolbar space used | down and/or have a toolbar that only showed text for items where it's | not clear what purpose they have. I have attached a file showing an Tool tips are specified in the toolbar creation, and I believe are specified for all toolbar elts. This idea of having text labels next to some subset of the toolbar icons strikes me as weird... who decides what toolbar elts have text next to them? And in GNC, I believe more often than not, our toolbar icons will disambiguating labels next to them; the operations here are "Schedule Transaction" and "Create new Account"... which are a bit harder to represent iconically. | expect to be the first one (Transaction) is the 4th. The menu's in | general in GnuCash are fairly confusingly laid out, for example if I'm [deletia] | How about a menu layout like this; [deletia] | I could go into a lot more detail here, but I do think we need to | rearrange the way we have the menu's laid out to make things easier to | find from a users perspective. I think this is mostly true; a think a full proposal, after some debate, would be a good thing to implement... :) | > Functionality Vector | > [deletia] | > off is left visually in place, but set to be insensitive, and thus the | > callbacks are not able to be invoked. Probably the right thing, then, to do | > is not attach the callbacks at all. | | This is good, having greyed out menu's indicates to the user they need | to do something in order to make it work. Well, unfortunately the user would likely be able to do nothing to make the non-functional bits work... it would be things [like "Schedule"ing a transaction w/in the SX Editor] that just don't make sense, but should be there so the user isn't confused when they disappear from the menus. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
RFC: refactoring window-register as widget-register + containing window
I'm attempting to fix something that came up earlier in the course of Scheduled Transaction UI development... where I needed to cut-and-paste a bunch of code from src/gnome/window-register.c into dialog-scheduledxaction.c to get a register in the SX Editor. I decided at the time that that was a to-be-short-term-lived hack to see if/how it all worked, and that something like this would be necessary, later. Now, as the SX since-last-run dialog wants two more "embedded" registers, it seems like time to do it. As this is a fairly major change, I'd like input before proceeding much further [i.e., actually making the changes], and definitely before committing back. ...jsled RFC: Refactoring window-register into a composite widget and containing window. Overview The Scheduled Transaction functionality desires to have multiple instances of the register available for its UI [SX editing of template transactions and review of created transactions in the since-last-run Druid]. For end-user convenience, these instances should look-n-feel as close to the window-register [src/gnome/window-register.c] as is possible. More specifically, there are four generically-useful bits in window-register.c: . the ledger_display itself . the toolbar . the popup menu . the status bar These UI elts are configured in static functions in window-register.c, and their callbacks are also static, leading to cut-and-paste for anyone else who wants to use the register + toolbar + popup + statusbar... and even more cut-n-paste to get the same behavior from the various toolbar buttons and popup-menu-items. Proposal I propose that these UI elts be brought out in a register composite widget [widget-register]. This widget would be a vbox which would contain the four widgets: toolbar, ledger_display, status bar and popup menu. [ I now utilize a distinction between the "window-register" [the existing register in src/gnome/window-register.c] and "widget-register" [the to-be-created register composite widget. ] Each of the widget-register's contained UI sub-elts is exposed to the caller for modification; for instance, the window-register itself adds the following toolbar actions: . close . transfer . find . report . print The popup menu, as well, will perhaps want to be modified by the caller; in the SX Editor, there is no menubar on the dialog... thus there is no menu bar for the actions which are currently in the window-register's Register, Edit and Transaction menus. A subset of the menu options provided by the window-register [such as modifying the display style, exposing cut/paste functionality] should be provided by the context/popup menu, or perhaps in the toolbar... but in any case, the caller will want to modify the existing menus where necessary to provide all appropriate functionality. This code would live in src/gnome-util/gnc-regwidget.[ch], with functions prefixed with "gnc_regwidget_". Supported - Looking at the window-register, there is a bunch of functionality present; looking at my initial cut-n-paste of [a subset of] the window-register.c code into the SX Editor, only some of this functionality was transfered over. Specifically, the widget-register should support: . Creation, by passing in the display_ledger to use, already configured for/with the appropriate type/Query. [ These are the common actions between the toolbar and popup menu... more importantly, they seem "common" to both uses of the register. ] . Enter . Cancel . Delete . Duplicate . Schedule . Split . Blank . Jump . Transfer . Style options . Basic, Auto, Journal . Double-line . Copy [split | txn] . Cut [split | txn] . Paste [split | txn] Unsupported --- The following functionality will be supported by the caller, if necessary [read: the window-register will support these, as the SX-based callers won't use it] . Sorting . Date-range selection . Account editing/creation . Check/repair . Find . Report . Print . Invoice . Stock splitting . Reconciliation Functionality Vector A goal of this effort is consistency: the user has experience with the window-register, and has created a mental map of actions and effects [and if they haven't, it will retard that map creation by having multiple different registers in different parts of the program]. Thus, the set of functionality that the widget-register supports should be configurable in such a way that not-available items ["Schedule..." while editing a Scheduled Transaction's template-transaction] are not removed, but only grayed out. This shall be done with a bitmask to be passed into the widget-register, specifying which functionality to turn off. Functionality which is turned off is left visually in place, but set to be insensitive, and thus the callbacks are not able to be invoked. Probably the right thing, then, to do is not attach the callbacks at all. Handling Actions Presently, the window-register direc
Re: Business Accounting Design Document, v0.1
On Tue, Nov 06, 2001 at 05:12:49PM -0500, Derek Atkins wrote:
| Design of a Basic Business Accounting Module
| Note that while most of these objects have an 'ID', the 'ID' is a
| counter and not a GnuCash GUID. This is because business processes
| seem to reference these objects by number (customer number, invoice
| number, sales order number), so having a GUID seemed superfluous and
| unnecessary. Also note that most objects state the ID should be
| unique -- by this I mean that there should only be one entry (row?)
| with that number.
That's not the point of GUIDs ... and it is the point.
GUIDs are an internal ID which is never visible to the user... as both ben
and grib commented, they basically replace C[++]-pointers in the backends
... but more importantly, they insulate the object relationships from
the user expressing a whim about their-level ID for a Customer/Job/&c...
I think you likely want both.
| The object descriptions here are mostly done in C, for simplicity.
| SQL Definitions can be easily derived, as most of these objects were
| shamelessly grabbed from JobTracker and SQL-Ledger SQL table
| definitions (or in many cases changed to suit the needs herein). In
| fact, these objects were designed specifically to be stored in a
| SQL-style database.
Why? Why does it matter? Do you have existing datastores that you want
to convert over?
| 2.1. Customer
| Customer {
[...]
| char *Name;
| char *Address1, * Address2, * Address3, * Address4;
| char *Contact;
| char *Phone;
| char *Fax;
| char *Email;
| char *Notes;
I'd recommend using VCard for contact info [this, and Shipping], if
possible... a) it's a level of detail and vocabulary that people are
used to and b) it's supported by other programs...
| int Terms;
Eh? I'm assuming this decodes somehow into "Net-15" , "Net-30" or
something...?
| bool TaxIncluded;
Is this really a property of a Customer?
| float Discount;
Eh?
| 2.2. Job
| Job {
| int ID;// unique id
| int CustomerID;
This is a case for GUIDs -- if the user changes their notion of a customer
ID, then you don't need to go fixup all the Job records...
| char *Name;
| char *Description;
If you really wanted to complicate^H^H^H^H^H^H^H^H^H^Hextend this, you
could add a table of notes ... but then ea. note has to have Authors and
Timestamps and Digital Signatures, Oh My!
| bool Active;
Perhaps 'date completed', and (!valid(date_completed) == active)?
| 2.3. Vendor
Comments as per 2.1 Customer apply.
| 2.4. Sales Order
|
| A Sales Order is an object that maintains order and service
| information. It is basically a collection of billable (or
| non-billable) items that are applied to a Job and will eventually be
| invoiced.
Thought:
Non-billable := zero amount split/transaction
Billable := non-zero amount split/transaction
Fixed-cost service = Billable
Material item = Billable
I wonder if that simplifies things at all... I guess you do want to be
able to list them seperately on the invoice, but perhaps that can be done
as a KVP-frame elt.
| SalesOrder {
| dateDate;
This is the date-of-billing? The date-of-sale? What if there's a 6-mo
sales cycle? Or even a 6-day sales cycle?
| float Tax;
How is this not just a split in the transaction?
| boolBilled;
Perhaps: date_billed and ( !valid(date_billed) -> !billed ) ?
| 2.6. Invoice
| Invoice {
[deletia]
| chat *Notes;
So this is an array of IM "chat" logs... ;)
| 2.7. Employee
| Employee {
| char *Language; // To allow customization of the UI
Seems like a UI thing, not an engine thing... the language choice the
user runs the interface with will allow all customization of the UI.
| char *ACL; // Access Control List, for system permissions
There was discussion about this a while ago, I believe, WRT the SQL
backend ... I don't believe that this necessarily should be a feature of an
engine object... it seems more like a UI/engine-consumer thing... perhaps
first-order "Credentials" are in order, but not for the engine...?
| float WorkDay; // Default work day
| float Rate; // Default Billing Rate
What if this varies per job?
For instance, on one job, I'm out of my element technically [it's highly
hardware-based], and I do docs... on another [highly software-based],
I do software. For the former, it's $30/hr ... for the latter, $80/hr.
| 2.8. Inventory
|
| Inventory is a short-term "asset" when you keep materials in stock but
| don't want to charge the expense all at once. The Inventory Object is
| a way to track what inventory you have in stock.
Seems like the recent PriceDB and Commodity work should apply wholly,
here... like a new Commodity type of description "Widget".
| 3.3. Inventory
[deletia]
| The only thing special about an Inventory account is that in order to
| purc
Re: Extending the TTInfo/TTSplitInfo data types?
On Sun, Nov 18, 2001 at 06:53:43PM -0500, Derek Atkins wrote: | What's implemented for TTInfo/TTSplitInfo is half of what I need for | Purchase/Sales Order information... Is it reasonable to try to extend | the template transaction interface so I can use it? I think so; there's some argument that says that the Template Transactions are a generally useful thing for GnuCash outside of the SX application which they came about in... something I've been thinking about, actually, is creating a "Create Transaction from Template" ... it doesn't have to be recurring/scheduled, but simply defines a cookie-cutter for the book entries. | Right now the TT | interface is fairly rigid. In what way? | Josh, do you have a preference how I add to the TT objects? In | particular I need to add the following fields to what currently exist: | date Well, I obviously don't want/need the date to be in the template transaction, but as it's the responsibilty of the caller to DTRT with the fields of the TTinfo structure, that'd be fine... | type / typeID What's a 'type'? How does this intersect with dave_p's recent [unannounced? -- I haven't cvs-updated in a couple of weeks] typed-GUID work? | qty / price / tax It seems like 'tax' is a split, a the qty/price stuff mimcs stocks/commodities ... hopefully you can extend the TTinfo stuff to take advantage of that ... which would be nice because the SX template transactions should also include the ability to create template Stock-account transactions at some point. See my reply to your design doc for more thoughts about this. | discount | invoiced? | invoice-ptr I get a bit worried when I see this ... I guess these are things that related to new first-class [business] engine objects, but I worry about what the interface will look like down the road: /* These apply to account transactions */ gnc_ttsplitinfo_set_credit_formula(...); gnc_ttsplitinfo_set_debit_formula(...); ... /* These apply to Invoiceable Items */ gnc_ttsplitinfo_set_invoice_status( bool ); gnc_ttsplitinfo_set_invoice_ptr( GUID invoicePtr ); /* These apply to Foo items */ gnc_ttsplitinfo_set_foo_this( ... ); gnc_ttsplitinfo_set_foo_that( ... ); /* These apply to Bar items */ ... I'm just worried it becomes fragmented-interface hell to support ea. kind of object in the system. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Scheduled Transaction design document?
On Fri, Nov 16, 2001 at 03:09:17PM -0500, Derek Atkins wrote: | It appears that there is both a template_accountgroup and a | schedxaction_accountgroup within a book. What is the relationship | between the two? I'll check on this when I get home; there should be only one or the other, no need for both. | Also, if the value of the split is 0, where do you actually keep track | of how much the split is "worth"? [deletia] | Is the real value part of the credit/debit formula? Indeed... though as it's a formula, any variables will need to be bound to values at transaction-creation time [there's ugly ui for this in the since-last-run Druid] to get a numeric for the real Split. | Thanks!! This does help a lot, and I think is a great model for what | I'm about to start working on. Ooh... can I ask what you're about to start working on? ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Scheduled Transaction design document?
On Fri, Nov 16, 2001 at 02:35:38PM -0500, Derek Atkins wrote:
| Is there a design document for Scheduled Transactions somehwere?
No. There are likely some messages in the -devel archives that hit on
various parts of it, but no single doc as such.
| I'm trying to understand how they are implemented, and a design
| doc would help speed up my understand.
A quick and dirty summary:
There are two engine objects: SchedXaction and FreqSpec.
FreqSpec is the frequency of recurrance specification, generically.
SchedXaction is the scheduled transaction data [name, bounds on the range
of recurrance [start/end dates, number-of-occurance data].
Scheduled Transactions have associated Template Transactions/Splits.
These are stored as 0-value Splits in an Account specific to the SX
[linked by GUID, stored in the SX], which are parented in a seperate/hidden
AccountGroup for Template Transaction data. These are written to the XML
backend in a ...
block, but are otherwise "normal" Splits and Accounts.
The _real_ account of the Split is stored in the KVP data of the template
split, as is the credit/debit formula.
In the SX editor UI, a special version of the ledger [a "template" general
ledger] is used to edit template transaction data; it redefines the
cell<->transaction handling rountines to load/store from the kvp frame...
The work of keeping the SX objects up to date is the job of the editor
and the since-last-run code.
SXes can be made from transactions via the code in
src/gnome/dialog-sx-from-trans.{h,c}, which makes use of
src/engine/SX-tt-info.{h,c} [tt == template transaction].
Gotta get back to work, but this should get you part of the way there;
I'll edit this more tonight and re-port it/put it in CVS.
...jsled
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: "error" in sched x-action
On Thu, Nov 01, 2001 at 04:24:31PM -0500, Derek Atkins wrote: | Error: gnc_frequency_setup: Inappropriate FreqSpec type [gnc-frequency: 1 vs. |FreqSpec: 1] Known; to investigate when I get some free time. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: POTFILES
On Wed, Oct 31, 2001 at 07:03:41PM -0500, Derek Atkins wrote: | make[2]: *** No rule to make target `../src/gnome/old-dialog-sxsincelast.c', needed |by `gnucash.pot'. Stop. Sorry... the present script which creates the POTFILES.in file picked up my attempt to keep a temporary backup as a file-o-compilation... this will be fixed in my next commit [unfortunately not for a few days, yet] ... quick fix: delete the line from POTFILES.in. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Since Last Run windows still popup
On Wed, Oct 31, 2001 at 08:54:19PM -0500, Derek Atkins wrote: | If there is nothing to do, please don't even pop up the dialog box Agreed. This was vexing me for a while, since I didn't [in the code] gtk_widget_show_all() the dialog unless and iff it had something to do. But this message prompted me to figure out WTF was going on. The problem crops up when I issue gnc_split_register_configure(...); it calls gnc_table_realize_gui(...), which causes the dialog to be shown... which is unfortunate. This occurs before I ask the dialog/widget to be shown [conditional on having something to do]. [ As dave_p points out, there's no reason to even create the dialogs if they're not necessarily going to be used. This will be fixed at some point soon. ] | There is nothing more annoying that having X "hang", waiting for user | input to place a window that is just going to be immediately | destroyed. ;) Some disparaging comment about your window manager could come into play, but I think that's just the bottle of wine talking. ;) ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: missing schec-xact_strings.c
On Mon, Oct 29, 2001 at 08:52:10PM -0800, Dave Peticolas wrote: | No, this isn't right. We no longer need to generate the strings file | for glade widgets -- the strings are pulled directly from the glade | xml sources by inttool. Nifty. | If you are seeing this error, your | po/POTFILES.in is out of date. Chris: To regenerate, remove src/gnome/glade/sched-xact_strings.c, and run './make-gnucash-potfiles > po/POTFILES.in'. | If you are working in glade, | do not turn on the option to generate the translatable strings | files. Turned off the in the sched-xact.glade file in CVS. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: missing schec-xact_strings.c
On Mon, Oct 29, 2001 at 12:07:31PM -0800, Chris wrote: | trying to build from CVS, I get | no rule to make target ../src/gnome/glade/sched-xact_strings.c needed by | gnucash.pot | | Anybody knowns where to get that missing file ? | The closest thing I found was sched-xact.glade. There's an option in src/gnome/glade/sched-xact.glade which saves all translatable strings to sched-xact_strings.c ... this is then included in the POTFILES.in [which is generated manually for our tree ATM]. The quick fix [option one]: open sched-xact.glade in glade and save the project; this will generate the file. If you don't have glade, let me know and I'll send you the file. The quick fix [option two]: remove sched-xact_strings.c from your po/POTFILES.in ... it shouldn't hurt anything, but since you'll be making a local change to your tree, you may run into CVS merge conflicts later. The real fix: we gotta figure out the right thing, here... It seems like we want to turn this option on in all the .glade files, so all the dialog text becomes translateable strings that fit into the rest of the system... but then there's this build issue. I guess we could check these files in periodically, but that doesn't exactly seem like The Right Thing. It does seem okay, though, as there's defined string freezes, which would be a good time to manually generate these files. ? ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Test report: Scheduled Transactions
On Tue, Oct 23, 2001 at 01:53:31PM -0400, Tim Wunder wrote: | Can I get the current balance of an account as a variable? Say, to get | the current principal balance of a loan for calculating interest for a | loan. The SX would look like: Hmmm... I was also thinking about this; automagically binding certain variables to various interesting information in the account. However, I don't think most users want to manually deal with the formula... though some will. I think we should further investigate the use of pre-defined functions to do this... furthermore, there should probably be some veneer of a dialog which allows the user to easily setup these splits [a-la the Funds Transfer dialog, which just sets up a bunch of splits]. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Test report: Scheduled Transactions
On Tue, Oct 23, 2001 at 01:29:55PM -0400, Derek Atkins wrote: | I didn't know the SX system could take formulas. Yes, that would Yes; I'm trying to figure out how to best inform the user about it... which makes me think of an interesting UI element: per-dialog "tip of the day". Especially on dialogs which represent new [new to the software or new to the user] functionality, it might make sense to have a user-configurable "explain new functionality" or something... I mean, it could just be in the docs, but who reads the docs? :) ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Test report: Scheduled Transactions
On Tue, Oct 23, 2001 at 12:49:35PM -0400, Derek Atkins wrote: | Richard -Gilligan- Uschold <[EMAIL PROTECTED]> writes: | Agreed. I'd like to be able to have gnucash determine the principal | and interest amounts for me, so I don't have to. In particular, I | _always_ pay-down my mortgage. I don't want to have to think about | the amount of principal/interest for each payment; that's what | computers are for! The current SX stuff contains support for ad-hoc variables and simple formulas [+-/*()]; when entered into the credit/debit cells, they will be brought out as vars to be bound in the SX-creation druid. One obvious area of extension to this [the "functionality I wasn't planning on implementing for a while"] was to have support for functions in there.. such that you could say credit:"principal( a, b, c )" or debit:"loan_payment( foo_loan )" or something. However, the UI is currently not quite "right" for even the simple-formula-containing SXes; and there's a whole host of issues [UI, code-wise, &c] related to this... | But I'm not sure how you get one split to automatically create a | second split. I don't think that that's the right way to go; why not just create the final picture, here, as the SX? ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Test report: Scheduled Transactions
On Mon, Oct 22, 2001 at 11:17:14PM -0400, Tim Wunder wrote: | OK. Finally got CVS with Scheduled Transactions to compile and my system | doesn't barf all over it... CVS stability seems to be at a time-local maxima. :) | 2 - My Sceduled Transaction set for 10/19/2001 for my wife's pay didn't show | up. Indeed; unless you had selected to have reminders about the transaction some number of days in advance, that will be empty. See further comments on empty pages below. | I'm then presented with a dialog called Auto-Created Transaction | Notifications. It displyed what looked to be part of my checking account | register, with the date highlighted, but no transaction data. I'm guessing | that this is where my wife's 10/19/2001 payday should appear. But it surely | wasn't there. Yes, it should have been there... in our IRC discussion, we subsequently saw it happen both ways... obviously merits some further investigation. | The display is quite whacked, too. You should have seen it when it was growing in 8- by 4-pixel increments w/o bound over the weekend... ;) But, yes... it doesn't quite draw itself correctly when that page is flipped to... something on my todo list. | Next dialog is the To-Create Transaction Preparation. Whatever that's | supposed to be...I think it needs a better name, perhaps "Pending | Transactions", or "Prepare Pending Transactions", or "Pending Transaction | Preparation", or "Prepare Transactions for Creation". Nothing was listed. I "Prepare Transactions for Creation" I like... I've never liked "Pending" because they're not... I think of "pending" as those that aren't in the process of being created... those that are out in the future. These are not pending: they either should have been created in the time intervale since you last ran GnuCash, or are to-be-created today... | know this, but I gotta say it, anyway, if there are none, don't present the | dialog. Indeed; this is a freshly-implemented dialog, and I didn't have time to complete it fully over the weekend. There's also some question about the best way to go about that; should it just not show those dialogs at all, or maybe tell the user up-front that "there's nothing relevant for the following stages of this dialog, so we'll skip them". I'm all about consistency so people can build mental maps and models, so simply dropping the pages worries me a bit. | Finally, I'm presented with an Obsolete Sceduled Transactions dialog. Hmmm. | What's this? My wife's payday is listed. But, my only option appears to be to | select it and delete it. I don't wanna do that. I wanna have it entered. I This turned out to be a freshly-introduced bug in the SX editor. :( It's fixed in my tree, should be in CVS later tonight... | leave it unselected and click . Nothing happens. Click | again, nothing happens. Click , nothing happens. Click , the | dialog closes. Yup... not-finished-dialog stuff. | Other thoughts, is there a way to configure a fixed loan, such as a mortgage | or auto loan, so that scheduled transactions are created for the loan? This | would be especially neat for those folks who have automated withdrawals done | for mortgaes. Indeed; this can probably be done, though my shallow initial thought about it is that it'd be benefited by some "advanced" SX functionality I wasn't planning on implementing real soon... I'll think some more about this in the near future. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Compile success!
On Tue, Oct 16, 2001 at 11:41:46AM -0400, Tim Wunder wrote: | re-ran ./configure --with-gnome=/opt/gnome (can this be specified when | executing autogen.sh?) Yes; all options given to autogen.sh are passed directly to configure. | I guess the segfault could be related to settings in my ~/.gnucash directory. | I'll probly try renaming that before I run gnucash again. Not all that likely; could be other bugs... gdb and backtraces are your [and our] friend. :) ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Sceduled Xactions
On Fri, Oct 12, 2001 at 10:49:17AM -0700, Josh Sled wrote: | The current state: | | . The scheduled transaction list and editor are implemented and workforme The list didn't, actually... deletion didn't really work. This has been fixed. | . Preferences [such as "by default, auto-create SXes" and "I want N lines | in my template ledger"] aren't hooked up, yet. This is no longer true; preferences are hooked up... there's an issue with the template reigster not expanding to fill available window space, but I'll get to that at some point. As well, I've added [some of] the "standard" register toolbar controls to the template register window in the SX editor. Some of these aren't implemented, and some are, but won't quite work ... the funds-transfer dialog, for instance, needs to be "templatized", creating the appropriate template transaction from whatever funds-transfer paramaters one wants. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Sceduled Xactions
On Fri, Oct 12, 2001 at 02:44:20PM -0400, Tim Wunder wrote: | Since my gnome version was not exactly the most current, simply | compiling 1.6.3 was non-trivial, requiring many lib updates. I learned | alot. Indeed; that's the bulk of the work for [current] CVS, as well... the nature of the changes recently is more to support the new module system [shared libraries, as evidenced by the automake/libtool versions required]... sort of meta-dependencies. | Will cvsup work with gnc's cvs tree? Any pointers in | using it before I jump in? Never having used cvsup, I don't know for sure, but if it's just doing the CVS remote protocol, it should work. But I've never found anything more than 'cvs -z3 update -dP' to be required [-z3: medium zlib compression, -dP: delete now-deprecated files and create/populate now-new directories]. Cheers... ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Sceduled Xactions
On Fri, Oct 12, 2001 at 12:59:54PM -0500, Clayton Carter wrote: | I'd just leave the window | open and save after everytime I added/edited anything. Anyway, I had | created an scheduled transation for my paycheck just to see how it all | worked. WRT this: another developer has noted that they generally run GnuCash like this, and would like the ability for the SX "since-last-run" dialog to open at a configurable daily [or perhaps otherwise] time... so this feature will make it way into the code at some point. | Was this a useful story? ;) Would you like me to go back and | try to dig up some more context? Some more context would be useful; if you have the datafile before ripping the SX sections out [note that there's a group that is SX related and can safely be removed as well], that'd be useful. Exact error messages are always useful. gdb backtraces are as well; I recommend running gdb from emacs, as then it'll easily allow you to see the source-file lines related. Also, a general note for producing backtraces: the 'bt' output is good, as well as going 'up' the stack a few frames, and performing an 'info locals' and 'info globals' on the last few stack frames... | Note, this wasn't the latest version | from CVS. (I tried downloading that and compiling, but it started | complaining about LIBTOOL or something.) Indeed; you need [I believe] the alpha 1.4 [not 1.5] automake, and a very recent libtool... I don't know the exact versions which are required... :( ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Sceduled Xactions
On Fri, Oct 12, 2001 at 10:23:36AM -0400, Tim Wunder wrote: | With that in mind, then, what is the current state of development of | scheduled transactions? The current state: . The scheduled transaction list and editor are implemented and workforme . The scheduled transaction "since-last-run" dialog mostly works... . "auto-create" transactions are created. . "auto-create, notify me" transactions are created, and you get notified in a general ledger for final editing/approval. . template-transaction-containing SXes are prompted for variables before creation. I'm not thrilled with the UI for this ATM, but it works... . I don't think the the recently-added "These are obsolete, delete them?" dlg works. . Creating a new Scheduled Transaction from one in the register doesn't quite work, as of the last time I checked [a few weeks ago]. . Preferences [such as "by default, auto-create SXes" and "I want N lines in my template ledger"] aren't hooked up, yet. You can look at src/doc/TODO-schedxactions for more detailed/up-to-date info... and known bugs. | Is it far enough along for testing by mere | mortals? I think so. I think it could begin to be used... in fact, I've been thinking about starting to myself on copies of my real datafiles... | Would such help be useful? Yes. Yes. Oh, and yes. Did I mention yes? :) In fact, I'm most curious about other users... there's already concerns about the UI and the user experience, but I disagree with those people... in any case, more/other input is needed. :) | I have a current version of gnucash installed (1.6.3), so I believe I | have what's needed to compile from cvs sources. The first step is to actually compile them... including the recent dependencies. This has often [unfortunately] been a non-trivial step in gnc development. Help is available on the list, or in #gnucash on irc.gnome.org. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: budgeting
On Mon, Oct 01, 2001 at 04:04:12PM -0700, [EMAIL PROTECTED] wrote: | Maybe what we should really be talking about is the *function* of a | budgeting subsystem. Yes. Below is a slightly-modified version of something I posted a while ago. Please review and let me know what you think... I guess I'm most curious about your comments on the user experience/flow ... not the initial/setup stuff so much, but more the applying budget to time frame... how does that work, and what useful info do you want it to provide you? ...jsled -- Budgeting in GnuCash jsled, 2000.11.09T0112, 2000.11.20T2337 Preface This document describes an approach to take at the problem of introducing functional budgeting into GnuCash. It presently borrows few ideas from GnuCash, and can be considered a general take at the problem of budgeting. It is not a design document, by any stretch of the reading; that will come later. It is more a set of notes relating to budgeting, and the basics of a framework for how budgeting might work. In this approach, budgeting is a primary yet optional function of GnuCash. It is an important tool for the user who wants to have a good grasp on their financial state; it is not a type of report. Budgeting is not strictly for people with income barely meeting their expenses [though the tool should be useful to them], nor strictly for the user with "extra" income looking for a way to reach their numerous savings goals. It should be flexible and functional enough to serve both users. Budgeting "budget" [Merriam-Webster] Main Entry: 1bud-get Pronunciation: 'b&-j&t Function: noun 1 chiefly dialect : a usually leather pouch, wallet, or pack; also : its contents 2 : STOCK, SUPPLY 3 : a quantity (as of energy or water) involved in, available for, or assignable to a particular situation; also : an account of gains and losses of such a quantity 4 a : a statement of the financial position of an administration for a definite period of time based on estimates of expenditures during the period and proposals for financing them b : a plan for the coordination of resources and expenditures c : the amount of money that is available for, required for, or assigned to a particular purpose - bud-get-ary /'b&-j&-"ter-E/ adjective A budget is a tool by which a user can compare expected expenses to the history of actual expenses, for the purposes of better allocating income. Once realistic budgetary limits are obtained, the user can then project forward to plan for future expenditures. The goal with any future-based financial tool is to manipulate the difference of income to expenses, in order to further utilize available financial resources. Functional Areas The basic idea of a budget is as follows: 1. Define recurring expenses. 2. Sum. 3. Subtract from income. 4. Adjust so difference is >= 0. ... but we can do much better. Basic The basic concepts in a budget are income, recurring expenses and time. Income can be fixed [as in salary or loans] or variable [such as in primary/suplemental income via a "as-desired" employment situtation or gifts/winnings]. Recurring expenses [now: "expenses"] can be typed into one of the following categories: Expense category types expense type examples notes fixed rent, loan repayment, cable, internet, insurance variable phone $[30,90], food $[400,600], gas $[25-35, every two weeks] seasonal utilities, gifts These will definitely be 'variable' in the first cut, and maybe will stay as that; but we can do so much better! :) sporadic car repair, emergencies, clothing, computer Time is hard to nail down. For some categories, the expense is incurred on a fixed date [rent is due on the first of the month; I pay it the first weekday after the first]. For other expenses or situations, the expense may acrue during a time-span. For instance, in my three-person apartment, I make a phone payment during the middle of the month [around the 20th], then collect payments from my apartment-mates during some amount of time after this. However, the budgeting system should not impose dealing with this situation on users with a simpler situation. As with most things financial, the budget is a zero-sum game. If you over-spend in one area, you must find some place to take this from. Likely candidates are [in order of priority]: 1. Unallocated income/savings [some catch-all category to enable 0-balance]. 2. Other budget areas which are under-run. 3. Savings goals [perhaps prioritized themselves; saving for a new Y-pipe is << important than grad sc
Re: budgeting
On Mon, Oct 01, 2001 at 04:04:12PM -0700, [EMAIL PROTECTED] wrote:
| Maybe what we should really be talking about is the *function* of a
| budgeting subsystem.
Definitely; see follow-on mail.
| In my mind, the purpose of a budget is to tell me how much money I have
| left to spend in a given period on a given type of item. That's what I
| want the budget to do.
Seems right.
[I think we have different ideas about a) what level of detail it
includes and b) how the implementation works to tell you those things,
but "yes". ;) ]
| I'm not interested in a budget that calculates interest on float,
| calculates finance charge interest on purchases, tells me which account
| to put my savings in, or any of that.
Well, I've always thought that these were optional, second-order functions.
However, it maybe useful to think about them now --- if it turns out that
a simple change now can make integrating that functionality much easier
later, we should probably do so.
| I want to know if, given the
| constraints that *I* have set, I can afford to buy a DVD player this
| month without adversely affecting my ability to pay rent, buy groceries,
| etc.
What are the nature of the constraints?
Is that decision made with knowledge of [available] lines of credit?
Should the budgeting system [be able to] tell you: "if you charge it,
but you don't have enough savings ATM".
If you plan to buy the DVD 6-months in advance, should the budgeting
system encourage/help you to save up that money for it?
What about Christmas gifts?
Or a vacation?
| I'm not suggesting that all those other features are boring and useless
| - far from it! Some of those calculations are *extremely* interesting
| to me (especially the interest on float one). It's just that I don't
| think those features belong in the budgeting subsystem.
Or, maybe not in the first cut of a budgeting system... or, you may very
well be right.
In the follow-on mail, let me know if you think that my Workbench idea
should be part of a "Budgeting" system, or part of something else... and
if so, what else?
| Why does a business user use a budget?
This is a very interesting question... while nothing jumps out at me as
being substantially different between personal and business budgeting
[except the size and granularity of the numbers involved], I could be very
wrong... hopefully someone can grab {small,medium,large}-business-finance
friends of theirs and get a one-two-page "business-budgeting
summary"... though I know this is asking too much.
...jsled
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: budgeting
On Sun, Sep 30, 2001 at 05:06:00PM -0700, [EMAIL PROTECTED] wrote: | FWIW, I don't personally care to know *where* my budgeted money is - I | have to manage my *physical* account balances separately from my | *logical* bucket system anyway. I think some people will care where it is, especially as it influences how accessible it is. I think for medium-to-long-term savings goals, it makes sense to take advantage of accounts available, such as moving savings out of my BofA savings account [at like 1% or whatever it is] and into a money-market [at like 4%]... or into a mutual fund which expects to get 10% over time... | the grocery store and charge it to my credit card. Now there's $435 left | in my grocery bucket... | | ... but no physical transfer of funds has taken place, nor is one likely | to take place for some time. Well, there's a change in your available credit, which may be interesting for other calculations. As well, there's the change in the 'used' amount of the budgeting category/bucket. | This will generate two *physical* transactions (Savings -> Checking, | Checking -> Credit Card) which, in turn, won't affect the buckets at | all. Well, the Savings -> Checking doesn't, but the Checking -> Credit Card does affect the available credit. If the bucket has the two values "allocated" and "used", then yes: the bucket is only affected when the charge is made. If the bucket has the three values "allocated", "used:held" and "used:disbursed", then the charge moves $65 from "allocated" to "used:held", and the Checking -> Credit Card xfer moves it from "used:held" to "used:disbursed". If we can do more interesting analysis with those three distinctions, we should have them. | So there doesn't seem to me to be a natural mapping between budgets and | physical accounts. Certainly. There's a set of mappings, and none of them natural... otherwise we wouldn't be talking about creating a tool to make our lives easier. :) | But this is really going to have to be managed by the user. Short of an | expert system, I don't see a really good way of implementing this. I don't think that it's _that_ hairy, but I acknowledge it may be so... I'm just throwing the idea out. If we find it's too hard, then we don't do it... but I think we should think about it, because if we can pull it off, it's a tremendously useful thing. | However, if the budget subsystem is doing it's job, then I, as the user, | should know *exactly* how much money is in my "Savings" budget, Yes... and you should know that you're contributing $X/(week/mo/quarter) to this savings goal because that's what will get the goal satisfied in the relevant amount of time. | which | will allow me to shift my physical monies between accounts as I see fit. If you desire to do so, you should be able to. However, my preference would be "tell me what account to put the money in to maximize utility... and better yet, schedule the transfers for me." Maybe the former is in phase II, and the latter in phase III... *shrug*. [ As you say in the other mail, we have differing views of how the user and the budgeting system interact :) ] | So, I spend $500/month on groceries, but | that $500 is actually sitting in my savings account until the bill is | due, so my grocery bucket generates $0.x of interest, which I will | probably apply to the "savings" bucket. I don't see a reason to re-assign | that special income to the "grocery" bucket. If it's really $0.x, then yes... But $500 @ 5% is $25, which is a tangible amount. And, in the progression of saving towards a large goal, the values involved may become less and less trivial over time. If I were smart, I'd be saving $1,000/mo right now. After 10 months, that's $10,000; in a 5% money market, that's $500/mo interest income... which is half of the $1000/mo contributions ... there are two relevant options, here: 1. Adjust payments to include interest income. 2. Don't, and allocate the interest income to some other purpose. I want this system to help me make the right decision in that case. The right decision is based on total income, other savings/financial goals [for instance, I may want to let the interest income go toward the savings goal after October, because a) it's already in the account and b) my "normal" income will be going towards Christmas gifts]. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: budgeting
On Fri, Sep 28, 2001 at 09:27:30PM -0700, [EMAIL PROTECTED] wrote: | come out of "Savings" anyway). The following month we then have an | "extra" $100, which flows down our chain of buckets and into a category | which doesn't always get filled (like "Discretionary"). So there's some policy for Budgeting Categories WRT unused portions of the allocated amount. The policy may be a ordered list of the following elements: . carry-over unused amount for next period . use unused amount for over-allocated categories . unused amount goes to 'pool' Others? Sound right? | At that point we *know* that we have $500 sitting in the bank, and we | don't have to stress about minor repairs or maintenance. I don't | necessarily care *where* that money is physically located, though, | because I can move money around at will in physical accounts. So the | "buckets" are logical entities completely separate from any specific | physical account. As I talked about in the mail to Todd, I think this is going to be true a lot of the time, but it won't be true in many other cases... | (A side effect of this is that when I charge | something to a credit card, I count is as "spent", but it's still | actually located in my savings account, so I accrue interest until I pay | the bill, and I'm *guaranteed* to have the money around to pay my credit | card bill, which means no finance charges). I think it's imporant that a budgeting system understands the notion of a credit card, and it's limit. There are expenses that you'll charge to a card for convenience, but are already "covered" in a savings location. There are other expenses, however, that may be budgeted for, but aren't already _saved_ for, and an implicit savings goal is created at the time of the charge, to be re-paid on an schedule appropriate to the financial picture. [ I know I'll have the money to pay for the shiney new gadgets I bought this week on credit, but I'll just allocate a bit of my income over the new few months to that, instead of savings up for it first... [instant gratification rules! :) ] ] | And now, to gnucash... >) To pull this off in gnucash, I think we | need another field in the register, which I'll call "category" for now. | If we tracked a "category" (notice: separate from expense - I track my | video rentals and movie tickets separately from an expense perspective, | but I budget $40 for "Entertainment" every month) for every expense, My thought about this has been that the budgeting category for "Entertainment" would be mapped to both relevant Expense categories, and thus no other "category" field is needed for splits/transactions. [terminiology is becoming a bitch, here :)]. | it'd be trivial to write a report which read a file containing your | monthly allotments and caps, then processed all your expenses and did | the math for you. Well, I've said before that I don't think the budgeting stuff can/should be shoehorned into a "report", but it depends on what the overall functionality is. And I don't think that budgeting info should be in anything external to the GnuCash data file. | Right now I do it using a *much* ickier and complicated procedure. I | can make it work in gnucash, so I know the basic philosophy is sound, | but without hacking some new code (which I don't have time for right | now), I'm forced to use a really kludgy manual system which I won't | describe here. Oooh will you describe it _here_? :) I'm very curious... about both levels of the process... | What would be the objections to adding a field to the register? How | much pain and suffering are we talking about? Could we add another | "style" of ledger, maybe, so that people who don't *want* the category | don't *have* to use it? Both options are feasible, and not _too_ hard. But I don't know if another field/column for the register is warranted. Moreso, I think we should attempt to have a minimal impact on the existing engine structures, as this is/should be an optional sub-system. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: budgeting
On Fri, Sep 28, 2001 at 03:04:06PM -0500, Todd T. Fries wrote: | Spreadsheet. Wife and I work on this together, and she only understands | Windows, so it's in excel. ;-( However, I was charged with finding a program | that fixes the problems we've thus encountered. So I have hope! ;-) >From my perspective, budgeting functionality in GnuCash seems at _least_ 3 months away... just for reference... | Currently we have a list of categories and sub-categories of places our | money goes. Income (my check), taxes, social security, groceries, | communications, etc. With breakdown of 1-2 levels in most cases, | imho very similar to the 'account name' sub-account concept. And would you agree that, while similar to the account hierarchy in concept and perhaps application, the budgeting hierarchy shouldn't be forced to be the same as the expense hierarchy? | AugustSeptember October | Allocated Total Spent Left Spent Left Spent Left | Income1000 1000 | taxes 300 7003000 3000 0 300 | social security 50 650 500500 0 50 | groceries 200 500172 28 210 18 0 218 | communications 100 4001000 1000 0 100 | 400 Okay, so to summarize, here: the primary sheet in the budgeting spreadsheet is a list of budgeting-categories [either in or out], with a time-period-based [generally monthly, here] allocation amount, and a per-time-period actually-used amount. The difference in the two determines the carry-foward amount between time periods. | And on another 'sheet' we have a running log of the money we bring in | and spend. I don't see how this is substantially different from the above... a little more detail, please? | I'm very much tempted to setup expense accounts to be the budget, so we | can track things that way. It would be very helpful if somehow I could | 'expense' something twice. Aka if I could write that the money, via an | electronic debit at a grocery store, disappeared from the checking account, | and was listed under both 'groceries' and 'Walmart'. I suppose I could | create an expense category 'groceries' and have 'Walmart' underneath of | it, but this doesn't help if I want the higherarchy to be: But that's not quite right, it seems. The fact that a transfer of money occured is encoded in one split [Memo: Walmart, split's account: checking, split's action: "debit" or "electronic debit" or something]; the fact that it was for groceries is encoded in the balancing split [memo: "food", account: expense.groceries]... with subsequent splits for any finer granularity you want on the line-items of the grocery receipt. Is there really a call for "Walmart" to have first-order involvement in the transaction? It seems like the goal here is to be able to say "we spent $x at Walmart, and $y at S-Mart", which I think can be done with a Transaction report [which doesn't seem to exist, yet] which can look at a subset of the transactions ... say, those which reference "Walmart"/"S-Mart" in the Memo field... | So until we 'save' enough to open a savings account, we're stuck keeping | track of it being 'available' somewhere between the checking, paypal, wallet, | and purse accounts, if you know what I mean. Yes, I know what you mean... [see below]. | I'd like to have, as I'm sure is common for others, the ability to specify | a budget effective for a period of time, that is pretty much the same for | each period of time beyond. Yes... it seems like a good use-case for the budgeting subsystem is along the lines of "let's take the existing/active budget and 'convert' it over to a perhaps-substantially-similar budget for the next N months". | We deal with a budget on a monthly basis, | although things like eating out would be nice to deal with on a weekly basis, | and other things, like car tag fees, on a yearly basis. Indeed... this is a somewhat tricky problem about all this. I think people want to deal with a budget on a monthly scale, most of the time. But, as is obvious, there are yearly [and multi-yearly] expenses which should be handled by the budgeting system, even when the month-to-month budget changes. And, people also want to be able to see on a daily basis where they sit WRT their budget... :I In fact, I think that's why you have the base-a-new-budget-on-the-previously-active-budget... because there's a lot of data about longer-term budgeted things that wants to be preserved and respected while the weekly- and monthly- things may shift around over time. | We also are | saving money for a few things, such as future 'hopefully not but everyone | knows how it goes' car repair, house, income reserve (economy suggesting Definitely want to support different savings goals, yes... and as Nato points out, these may be "capped" in useful ways [we should save until we have 3x
Re: Ofx and Budgeting support
On Thu, Sep 27, 2001 at 05:33:53PM -0700, [EMAIL PROTECTED] wrote: | I currently want to budget $40 for "Entertainment" every month, but I | want to track the expense using "Movie" (i.e. "we went to a movie") and | "Video" (i.e. "we rented a video"). This way I can tell how often we | blow our budget on going out to the movies versus the much cheaper | rental route. | | Does that count as a good example? Works for me. In fact, I think that'll be the canonical example... :) ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Ofx and Budgeting support
On Fri, Sep 28, 2001 at 09:59:17AM +1000, Phillip Shelton wrote: | It is just that this use of the word is what gets the new users from Quicken | confused as there are no longer any Quicken type categories and the docs say | to use accounts. Yes yes... you're right, and that could be easily confusing... I'm all about Correct Names for things, and that one in particular wouldn't work... | Or are you thinking of being able to group more than one | account under a category? I think that the user may want to budget at a different level than their income/expense account hierarchy... For instance, I might have 5 sub-accounts for various specifications of things, but want to budget them all as one item [I'm finding it hard to come up with an example, but I'm at work :)]... As well, it maybe the case that I have one expense account [for food, for example], but want to budget it in more detail [$A/mo for dinners made by me, $B/mo for dinners out on the town, $C/mo for workday-lunches, &c.]. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Ofx and Budgeting support
On Wed, Sep 19, 2001 at 08:12:11PM -0500, Matt Kowske wrote: | category is over-budget, the user could maybe be able to choose which of | their other budgets they would like to take away from for this month to | compensate. something to that effect anyway, does this sound like | something that could work? I don't see why not... It depends -- of course -- on how the budgeting system is designed and implemented. Since that's not really done, there's no way to tell exactly how hard that would be or how quickly it would be done. There's also a question of how useful that functionality is if it's at the level of category selection to cover expenses... perhaps it's sufficient to say: "you had $X over-budget [combined across categories] and $Y under-budget [across categories] Y - X >= 0, so you're okay for the month... do you want detail about your over-budget categories?" Hmm... obviously more thought to be done... ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: bug in xaccFreqSpecGetFreqStr (?)
On Fri, Sep 21, 2001 at 01:02:57PM +1000, Robert Graham Merkel wrote: | On Fri, 21 Sep 2001 12:35:39 Robert Graham Merkel wrote: | > I've just found a bug in the "SX from real trans" dialog. Create a | > scheduled transaction of | > "weekly" freqency using the schedule button, then try to view that | > transaction in the Scheduled | > Transactions list. Instant segfault. | > | > The problem seems to be that xaccFreqSpecGetFreqStr is looking for a | > composite freqspec, when | > we've got a weekly one. Why? | > | | Sorry to reply to my own message, but it seems that when the full-blown | sx editor sets a weekly SX, it creates a composite freqspec and goes | through | all sorts of gyrations. . . Josh, could you explain the rationale here? A 'weekly' FreqSpec stores a single day of the week. Therefore, to create a [single- or] multi-day weekly SX, we create a Composite FreqSpec which contains 'N' weekly FreqSpecs [one of ea. DOW selected by the user]. I guess that assumption is implicit in the GetFreqStr code, but the "SX from real trans" dialog sets it up with a single weekly freqspec... the fix would be to make the SX-from-real code create a "proper" weekly FreqSpec, and to remove/make visible that assumption/paradigm [a weekly is really a composite of weeklyies]. ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: xml-i18n-tools
On Tue, Sep 18, 2001 at 11:28:12PM -0700, Darin Adler wrote: | As you can see in the bug report, the autoconf maintainer has already | weighed in and said, "newlines are not compatible with sed" :-) Heh... | Maciej has told me in the past that removing the newline-escape in those | lines results in an expansion that doesn't actually make working make rules. | You said that you have verified that the fix works -- maybe we're lucky and | Maciej was mistaken, or maybe you just didn't test any case where the make | rule had to work. Well... I verified that it didn't b0rk when creating the Makefiles... :) On subsequent _use_ of those makefiles, the error you/Maciej describe is encountered. | Maciej also told me that he has an idea in mind for a real fix that will | avoid this problem and be guaranteed to work properly. I look forward to it... :) Thanks for the prompt response... ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: xml-i18n-tools
On Mon, Sep 17, 2001 at 02:59:50AM -0700, Dave Peticolas wrote:
| If you are compiling gnucash from CVS, you will need to obtain
| the xml-i18n-tools package from
|
| http://ftp.gnome.org/pub/GNOME/stable/sources/xml-i18n-tools
Note: xml-i18n-tools-0.8.1-ximian.1 [from Ximian Gnome 1.4, I think]
won't suffice... 0.9 works [except, see below]; I don't know in which
intermediate version the fix was made.
I have noticed one problem, however [for which the xml-i18n-tools guys
are CC'd on this]...
xml-i18n-tools.m4 defines a bunch of expansions like:
XML_I18N_MERGE_KEYS_RULE='\%.keys : \%.keys.in $(top_builddir)/xml-i18n-merge
$(top_srcdir)/po/*.po\
$(top_builddir)/xml-i18n-merge -k $(top_srcdir)/po $< [$]*.keys'
These then get included into config.status verbatim, and used in a
here-document output to "/tmp/cs-/subs.sed" [the first step of
the CONFIG_FILES section]... In this case, this .sed file is rather long
[203 lines]... but config.status wants to be smarter than that, and the
here-doc is immediately followed by the following bit...
config.status> # Split the substitutions into bite-sized pieces for seds with
config.status> # small command number limits, like on Digital OSF/1 and HP-UX.
config.status> ac_max_sed_lines=48
...where it subsequently breaks the 203-line .sed file into 48- [really
50-] line chunks.
However, I happened to get unlucky enough to have it perform
that split in the middle of one of those newline-escaped
XML_I18N_MERGE_{OAF,SERVER,...,XML}_RULE lines, which naturally produces
the following two errors when attempting to produce every Makefile in
the gnucash tree...
config.status: creating Makefile
sed: file /tmp/cs20946-13181/subs-3.sed line 51: Unterminated `s' command
sed: file /tmp/cs20946-13181/subs-4.sed line 3: Unknown command: ``(''
For reference, here are the tail and head [respectively] of subs-3.sed
and subs-4.sed:
jsled@phoenix$ [/tmp/cs21140-3012] tail -3 subs-3.sed
s,@XML_I18N_MERGE_SERVER_RULE@,\%.server : \%.server.in $(top_builddir)/xml-i18n-merge
$(top_srcdir)/po/*.po\
$(top_builddir)/xml-i18n-merge -o $(top_srcdir)/po $< $*.server,;t t
s,@XML_I18N_MERGE_KEYS_RULE@,\%.keys : \%.keys.in $(top_builddir)/xml-i18n-merge
$(top_srcdir)/po/*.po\
jsled@phoenix$ [/tmp/cs21140-3012] head -3 subs-4.sed
:t
/@[a-zA-Z_][a-zA-Z_0-9]*@/!b
$(top_builddir)/xml-i18n-merge -k $(top_srcdir)/po $< $*.keys,;t t
The easy fix [verified] is to remove the newline-escape in those lines in
xml-i18n-tools.m4 ... the Right fix is probably to fix whatever generates
config.status to do better .sed-file chunking.
...jsled
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Ofx and Budgeting support
On Tue, Sep 11, 2001 at 08:56:48PM -0700, [EMAIL PROTECTED] wrote: | On 10 Sep, Willits, Darin wrote: | | > I would really like to start using gnucash on a daily basis but these two | > things are standing in my way at the moment. I am willing to help out and | > work on these things but before I start I wanted to make sure I am not | > duplicating any effort. | | | I'm interested to know who might be working on budgeting, also. I've | started to implement some systems on my local system here, but I don't | currently have time to prepare and submit patches (maybe in a couple | months). I'd really like to talk, though, about what the budgeting | system should look like. That'd be me. I intend to start work on budgeting once scheduled transactions are finished... that's probably ~2 months out. I think talking/design work is very appropriate... I tried very persistantly for a few months to pin down a good budgeting design, and failed to come up with something that said "that's it" to me immediately and I'm really curious about how people think the budgeting stuff should work/look... the best thing to do would be to read the relevant threads of the -devel archives from ~Nov/Dec 2000, then post your thoughts to -devel, or try and meet up with me in #gnucash... ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: gnucash-devel digest, Vol 1 #726 - 8 msgs
On Sun, Jul 01, 2001 at 01:55:41PM -0400, Michael T. Garrison Stuber wrote: | > | At work, in completely unrelated software, we often focus on the | > | number of mouse clicks required to perform common tasks as a measure | > | of usability. | | I'll chime in here, on a similar vein. At work, we require our GUI guys to | make sure everything you can do with a mouse you can also do easily with a | keyboard. There are a couple of places where your forced to use a mouse | whether you want to or not (either that or the keystrokes are so counter | intuitive I have yet to figure them out -- I haven't examined the source | code on those dialogs) Yes... I was thinking last night about this while walking home from dinner. I was thinking in the context of limited-input mobile devices [GnuCash running unaltered on a perhaps-souped-up-iPaq]... there should be no requirement for a mouse, anywhere in GnuCash. I've already recorded a problem I've seen in the Scheduled Transaction Editor, where one cannot click or tab out of the register... but there is also simply un-finished work in setting up the tabbing order and keyboard accels on all the scheduled-transaction-related GUI stuff I've done so far [it's only finished to the extent that Glade automagically does it]. If you feel like helping out, jumping in and adding appropriate accelerators to the scheduled transaction stuff would be very much appreciated! [ Don't worry about the "Since-last-run" dialog at the moment, however, as I think it's going to get shot in the back of the head, maybe even in a couple of hours. ] ...jsled PS: It'd be helpful to quote the Subject/Author of the post/thread in the Digest version which you're replying to... ideally in the subject line of the message, but at least in the body... ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Scheduled Transactions patch, Mk I
On Mon, Jun 18, 2001 at 08:29:43AM -0400, [EMAIL PROTECTED] wrote: | What is this built against? I tried to apply the "I.1" patch to the | 1.6.0 sources and it failed. I'd like to try it out and give | feedback but I have to build it first! The first patch was against CVS ca. Saturday 7pm. The second cleaned-up patch was against CVS ca. Sunday 5pm... [all times Pacific]. The second version of the patch is now in CVS, causing no end of annoyance to people who compile with warnings-as-errors flags; it will be cleaned up soon. | The other, more important question is... are we targeting this for 1.8 | or a 1.6.x release? Feels like 1.8, though given enough work it might make 1.6.x... ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Forcasting Graphs/Reports
On Tue, May 22, 2001 at 04:31:27PM -0700, Dave Peticolas wrote: | On 22 May 2001 14:26:51 -0700, [EMAIL PROTECTED] wrote: | > In the past, I started using gnucash and stopped because there is a feature in MS |Money that I am addicted to. MS Money takes into account all of your recurring |payments and deposits and generates a report/graph that forcasts you account balance |however many months into the future that you wish to see. I've found this to be |indispensable when planning purchases so that they won't run my account over budget |down the road. | | Basically you are talking about budgeting here, right? | Currently, there is no support for that, but several | people are interested in working on it in the next | development cycle. If you wanted the simple report and are anxious to get started, you could start on implementing it off of either CVS, or the recent 1.5.96 version. 1.5.x is in freeze for 1.6, so it can't go in now, but the code is there and waiting to be ammended... If you want a more functional budgeting tool... indeed, some of us are itching to work on that post 1.6. I've been making large strides toward a related feature of scheduled/recurring transactions, which will go in post-1.6. After scheduled transactions are mostly settled, I plan to devote my full, partial time to budgeting... The -devel archives are at http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel, and you can find some archives of budgeting discussion in the late-November through early-January timeframe. I hope to re-start that discussion in a couple of weeks... Cheers... ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scheduled transactions
On Sun, May 20, 2001 at 01:54:25AM -0400, [EMAIL PROTECTED] wrote: | Let's put it this way: In theory, yes... but in practice, if budgeting | is nearly as complicated as it is in Quicken, How is it complicated in Quicken? I guess I can only really answer this by playing around with Quicken, but even when I do that I might not find it complicated, or find it complicated in a different way. So I'm curious as to why you [and others] find it lacking. | or nearly as complicated | as your previous descriptions (was it all the way back in December or | February) then I want no part of it. I didn't think my previous descriptions were all that complicated, but they were definitely unfinished throughts... :) I intend to start a new thread of discussion about budgeting before 1.6 is released, so that interested parties can begin to come to an agreement about what to start working on post-1.6... I'm on vacation from 5/25 to 6/3, so I'll probably post out sometime during the week of the 3rd. | Every so often I try to use budgeting in Quicken to see if I can make | sense of my budget, but it's too much work to convert the result of | the auto-import into something meaningful. I have done it a few times, When you say "auto-import", you mean a mechanism by which Quicken attempts to construct a budget out of your existing transactions? Indeed, that seems like a far-from-trivial problem... I've been thinking of punting on that for a while, in fact. | scheduled transactions in Q leave something to be desired. It sounds | like you've filled that in... your description from last week sounds a | lot like my wish list. (Thanks!) Excellent. And it gets better every day. Last night I got simple recurring transactions [those involving only numeric values [not formulas] created and entered in the books. :) I hope to make a patch tonight, but it still won't go into CVS for a few weeks, yet... if I'm a bad-ass, maybe I can compile a static version and post that somewhere... [any advice on this?] | I also mentioned before that scheduled transactions could be holding | back a lot of people from making the switch, so the sooner the gang | sees fit to include them in a stable build, the better. Indeed. We'll have to talk about this post-1.6... ...jsled ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Automatic periodic actions
On Sun, May 06, 2001 at 02:57:38PM -0700, Dave Peticolas wrote:
| I think scheduled transactions will definitely be in 1.8, or whatever
| the stable version after 1.6 is called. Joshua Sled is getting close
| to a version of scheduled transactions that should go into CVS shortly
| after 1.6 is released.
"Josh", please... :) .muttrc changed as appropriate. :)
Yes, indeed. Scheduled transactions are shaping up quite nicely...
I can [after a bit of a hiatus], as of tonight, create a scheduled
transaction for any frequency of {once, daily, daily [m-f], weekly,
bi-weekly, semi-monthly, monthly, quarterly, tri-anually, semi-yearly,
yearly} [thanks to the wonderful recurrance code of Ben Stanley]...
The "template transaction" which will be created when the next instance
of that scheduled transaction "comes due" is correctly handled: each
scheduled transaction has its own set of transactions/splits to be created.
The credit/debit areas of these transactions will accept formulas
[presently a text/QuickFill cell]. The idea is that these formulas will
contain variables which are relevant to a particular instantiation of the
transaction, and will be filled in by the user at the appropriate time.
The amount of a utilitiy bill, for instance... or "0.33 * total", for a
bill evenly split between three people.
This template-transaction code uses a modified version of the general
ledger, for similarity to the rest of the program...
Scheduled transactions [and their component frequency specifications
and associated transactions] are saved and restored from the v2 XML
file... other backends are not handled.
Next up is the "since-last-run" code and the forward-looking code which will
show the next N months [configurable] of transactions in the appropriate
register...
I expect that some form of all this will go into CVS very shortly after
1.6 is released...
Attached is a pics of the state of things; I will post an 'advisory'
patch [hopefully] next weekend...
:)
Cheers...
...jsled
20010513-windows.png
