[patch] Save last used post-to accounts in owners kvp frames
Hi, I wonder whether the attached patch, applicable to trunk, is desirable for those that use the business functions. I usually do not touch that code :-) As of r16773 there is no default account selected in the account selection widgets of invoice/bill/expense voucher post-to dialogs. The patch tries to save the last used account in the kvp slot last-posted-to-acct of the effective invoice owner (i.e. owner of job if the job is the owner). Before showing the post-to dialogs it tries to read that slot and pre-selects the account appropriately. Comments? -- andi5 Index: src/business/business-gnome/dialog-date-close.c === --- src/business/business-gnome/dialog-date-close.c (Revision 16771) +++ src/business/business-gnome/dialog-date-close.c (Arbeitskopie) @@ -103,9 +103,7 @@ gnc_account_sel_set_acct_filters( gas, ddc-acct_types ); gnc_account_sel_set_new_account_ability( gas, TRUE ); gnc_account_sel_set_new_account_modal( gas, TRUE ); - - /* XXX: Some way to remember the last selection? */ - gnc_account_sel_set_account( gas, NULL ); + gnc_account_sel_set_account( gas, ddc-acct ); } static void @@ -248,6 +246,7 @@ ddc-ts2 = post; ddc-book = book; ddc-acct_types = acct_types; + ddc-acct = *acct; ddc-memo = memo; ddc-terms = terms; @@ -357,6 +356,7 @@ ddc-ts = date; ddc-book = book; ddc-acct_types = acct_types; + ddc-acct = *acct; xml = gnc_glade_xml_new (date-close.glade, Date Account Dialog); ddc-dialog = glade_xml_get_widget (xml, Date Account Dialog); @@ -364,6 +364,8 @@ acct_box = glade_xml_get_widget (xml, acct_hbox); ddc-acct_combo = gnc_account_sel_new(); + if (*acct) +gnc_account_sel_set_account (GNC_ACCOUNT_SEL(ddc-acct_combo), *acct); gtk_box_pack_start (GTK_BOX(acct_box), ddc-acct_combo, TRUE, TRUE, 0); date_box = glade_xml_get_widget (xml, date_box); Index: src/business/business-gnome/dialog-date-close.h === --- src/business/business-gnome/dialog-date-close.h (Revision 16771) +++ src/business/business-gnome/dialog-date-close.h (Arbeitskopie) @@ -41,6 +41,8 @@ * Note that the dialog will own (and free) the acct_types list. * it should be a list of GNCAccountTypes. If memo is non-NULL, * it will g_malloc() a string. The caller should g_free() it. + * The value of *acct will be used as preselection of the account + * selection widget. */ gboolean Index: src/business/business-gnome/dialog-invoice.c === --- src/business/business-gnome/dialog-invoice.c (Revision 16771) +++ src/business/business-gnome/dialog-invoice.c (Arbeitskopie) @@ -76,6 +76,8 @@ #define GCONF_SECTION_SEARCH dialogs/business/invoice_search +#define LAST_POSTED_TO_ACCT last-posted-to-acct + void gnc_invoice_window_ok_cb (GtkWidget *widget, gpointer data); void gnc_invoice_window_cancel_cb (GtkWidget *widget, gpointer data); void gnc_invoice_window_help_cb (GtkWidget *widget, gpointer data); @@ -593,6 +595,9 @@ GList * acct_types = NULL; Timespec ddue, postdate; gboolean accumulate; + QofInstance *owner_inst; + KvpFrame *kvpf; + KvpValue *kvp_val; /* Make sure the invoice is ok */ if (!gnc_invoice_window_verify_ok (iw)) @@ -641,6 +646,11 @@ ddue = postdate; memo = NULL; + owner_inst = qofOwnerGetOwner (gncOwnerGetEndOwner ((iw-owner))); + kvpf = qof_instance_get_slots (owner_inst); + acc = xaccAccountLookup (kvp_frame_get_guid (kvpf, LAST_POSTED_TO_ACCT), + iw-book); + /* Get the default for the accumulate option */ accumulate = gnc_gconf_get_bool(GCONF_SECTION_INVOICE, accumulate_splits, NULL); @@ -658,6 +668,13 @@ gncInvoiceBeginEdit (invoice); gnc_invoice_window_ok_save (iw); + /* Save acc as last used account in the kvp frame of the invoice owner */ + kvp_val = kvp_value_new_guid (qof_instance_get_guid (QOF_INSTANCE (acc)));; + qof_begin_edit (owner_inst); + kvp_frame_set_slot_nc (kvpf, LAST_POSTED_TO_ACCT, kvp_val); + qof_instance_set_dirty (owner_inst); + qof_commit_edit (owner_inst); + /* ... post it; post date is set to now ... */ gncInvoicePostToAccount (invoice, acc, postdate, ddue, memo, accumulate); gncInvoiceCommitEdit (invoice); ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [patch] Update README files for Debian dependencies
Hi Jerry, Am Sonntag, den 30.12.2007, 14:10 -0500 schrieb Jerry Quinn: As I was resolving the dependencies I needed to build gnucash out of svn, I updated the README files somewhat to reflect the current status quo on Debian testing. I tried to capture what I needed both for the automake run as well as configuring and building. I also updated the Debian package version lists in README.dependencies. I checked the versions against stable as well, so I think it's ok. Let me know if anything is amiss. Thanks, I really wonder whether this type of information should only be held at the GnuCash wiki as it tends to become outdated pretty easily. Just my 2 ¢. -- andi5 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
QIF importer bug in GC 2.2.2 - split transactions
Hi, I think it'll be easier to explain with a little context. I have hundreds of paycheck entries in Quicken 2004 each of which is a split transaction that has (among other things) two transfers from a checking account to a retirement account: one for the employee's contribution and one for the employer's matching contribution. These are for the same amount, between the same accounts, with only the memo field different. The importer seems to remove these Quicken account - Quicken account transfers from the split and put them into new separate GC transactions. That part is fine (actually I wish it wouldn't but the account balances are still correct). The Quicken account - Quicken category transfers remain in a GC split transaction. The problem is that one of the retirement transfers *also* stays in the GC split transaction. In other words, where we originally had two transfers from checking to retirement we now have three. The problem disappears if the amounts are different. The memo field doesn't seem to change anything (in fact it gets attached to the wrong part of the split but I vaguely remember seeing that bug/feature already reported). Anyway, I created a sample QIF file (attached) that demonstrates the behavior. I didn't see anything in bugzilla but there are an awful lot of importer bugs :-) and I may have missed it. I'm quite happy to file a bug report if people think this is a real and not a dupe. I'm most interested in a more immediate workaround if anybody has ideas: either on the Quicken end or via a patch to the importer or even just a pointer to where in the source I should look. Thanks in advance, - Bill!Option:AutoSwitch !Account NChecking TBank ^ NIRA TPort ^ !Clear:AutoSwitch !Option:AutoSwitch !Account NChecking TBank ^ !Type:Bank D12/31' 7 U1,000.00 T1,000.00 PPaycheck LSalary SSalary $1,400.00 S[IRA] $-200.00 S[IRA] Eemployer matching $-200.00 ^ !Account NIRA TInvst ^ !Type:Invst D12/31' 7 NContribX PPaycheck U200.00 T200.00 L[Checking] $200.00 ^ D12/31' 7 NContribX PPaycheck U200.00 T200.00 Mmatching L[Checking] $200.00 ^ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
account summary separately for each cost center
Hi,
I recently tried to get account summaries separately for each cost
center (e.g. physical location or subdivision of a company). The thread
https://lists.gnucash.org/pipermail/gnucash-user/2007-October/022074.html
came to the conclusion that the Action field could be used to
specify cost center but later I was told that it is per split and not
per transaction so I thought I'd better (ab)use the Notes field
instead.
I first tried to modify account-summary.scm but then noticed that even
though there is gnc:query-add-description-match there is no
gnc:query-add-notes-match.
Finally I resorted into writing a small python program that reads a
gnucash file and prints a primitive account summary separetely for
each cost center:
$ wget http://iki.fi/lindi/darcs/gnucash/cost-center/{cost-center,example}
$ python cost-center example
Cost center Helsinki
==
Savings Account -5.0
Other Income -10.0
Miscellaneous 15.0
Cost center New York
==
Savings Account -4.0
Other Income -5.0
Miscellaneous 9.0
I don't know if this is useful to anyone but I thought I'd post to get
comments and so that somebody could find this with a search engine ;-)
best regards,
Timo Lindfors
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: account summary separately for each cost center
Quoting Timo Lindfors [EMAIL PROTECTED]: Hi, I recently tried to get account summaries separately for each cost center (e.g. physical location or subdivision of a company). The thread https://lists.gnucash.org/pipermail/gnucash-user/2007-October/022074.html came to the conclusion that the Action field could be used to specify cost center but later I was told that it is per split and not per transaction so I thought I'd better (ab)use the Notes field instead. I first tried to modify account-summary.scm but then noticed that even though there is gnc:query-add-description-match there is no gnc:query-add-notes-match. Adding this would be fairly easy Finally I resorted into writing a small python program that reads a gnucash file and prints a primitive account summary separetely for each cost center: Would you be willing to write a scheme report if the above API were available? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QIF importer bug in GC 2.2.2 - split transactions
On Mon, Dec 31, 2007 at 01:11:22PM -0500, [EMAIL PROTECTED] wrote: Hi, I think it'll be easier to explain with a little context. I have hundreds of paycheck entries in Quicken 2004 each of which is a split transaction that has (among other things) two transfers from a checking account to a retirement account: one for the employee's contribution and one for the employer's matching contribution. These are for the same amount, between the same accounts, with only the memo field different. The importer seems to remove these Quicken account - Quicken account transfers from the split and put them into new separate GC transactions. That part is fine (actually I wish it wouldn't but the account balances are still correct). The Quicken account - Quicken category transfers remain in a GC split transaction. The problem is that one of the retirement transfers *also* stays in the GC split transaction. In other words, where we originally had two transfers from checking to retirement we now have three. Are you sure you're not confused by the multiple entries to the same account causing the txn to show up twice? IOW, If you enter a txn and have a credit to checking and two debits to the same other account, fromt that other account, the txn will look like *two*. You could test this by deleting the txn and seeing that both entries disappear. The problem disappears if the amounts are different. The memo field doesn't seem to change anything (in fact it gets attached to the wrong part of the split but I vaguely remember seeing that bug/feature already reported). There is a fix in trunk for some of the QIF memo/notes issues that will hopefully be in 2.2.3. Anyway, I created a sample QIF file (attached) that demonstrates the behavior. I didn't see anything in bugzilla but there are an awful lot of importer bugs :-) and I may have missed it. I'm quite happy to file a bug report if people think this is a real and not a dupe. I'm most interested in a more immediate workaround if anybody has ideas: either on the Quicken end or via a patch to the importer or even just a pointer to where in the source I should look. Haven't looked at your sample yet, but will later today. A signature.asc Description: Digital signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: account summary separately for each cost center
Hi, Derek Atkins [EMAIL PROTECTED] writes: I first tried to modify account-summary.scm but then noticed that even though there is gnc:query-add-description-match there is no gnc:query-add-notes-match. Adding this would be fairly easy Finally I resorted into writing a small python program that reads a gnucash file and prints a primitive account summary separetely for each cost center: Would you be willing to write a scheme report if the above API were available? I could certainly take a look at it. Why not add some generic gnc:query-add-field-match that would take the field name as an argument? best regards, Timo Lindfors ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QIF importer bug in GC 2.2.2 - split transactions
On Dec 31, 2007 1:10 PM, Andrew Sackville-West [EMAIL PROTECTED] wrote: On Mon, Dec 31, 2007 at 01:11:22PM -0500, [EMAIL PROTECTED]: Hi, I think it'll be easier to explain with a little context. I have hundreds of paycheck entries in Quicken 2004 each of which is a split transaction that has (among other things) two transfers from a checking account to a retirement account: one for the employee's contribution and one for the employer's matching contribution. These are for the same amount, between the same accounts, with only the memo field different. The importer seems to remove these Quicken account - Quicken account transfers from the split and put them into new separate GC transactions. That part is fine (actually I wish it wouldn't but the account balances are still correct). The Quicken account - Quicken category transfers remain in a GC split transaction. The problem is that one of the retirement transfers *also* stays in the GC split transaction. In other words, where we originally had two transfers from checking to retirement we now have three. Are you sure you're not confused by the multiple entries to the same account causing the txn to show up twice? IOW, If you enter a txn and have a credit to checking and two debits to the same other account, fromt that other account, the txn will look like *two*. You could test this by deleting the txn and seeing that both entries disappear. Andrew, I looked over the QIF file and tried importing it and this is definitely a bug. I seem to recall having the very same problem recently, but I haven't followed up on it because the number of affected transactions was tiny (I think I fixed them by hand). I also encountered bug 114724http://bugzilla.gnome.org/show_bug.cgi?id=114724during my imports which may or may not be related. The problem disappears if the amounts are different. The memo field doesn't seem to change anything (in fact it gets attached to the wrong part of the split but I vaguely remember seeing that bug/feature already reported). There is a fix in trunk for some of the QIF memo/notes issues that will hopefully be in 2.2.3. Bill, if you feel like a walk on the wild side, you could test the notes fix for bug 495219 http://bugzilla.gnome.org/show_bug.cgi?id=495219 by downloading the latest version of qif-to-gnc.scm herehttp://svn.gnucash.org/trac/browser/gnucash/trunk/src/import-export/qif-import/qif-to-gnc.scm?format=txt. It just replaces the one already installed on your system. It won't fix your main problem with the transfers though - I already tried it with your test file. Anyway, I created a sample QIF file (attached) that demonstrates the behavior. I didn't see anything in bugzilla but there are an awful lot of importer bugs :-) and I may have missed it. I'm quite happy to file a bug report if people think this is a real and not a dupe. I'm most interested in a more immediate workaround if anybody has ideas: either on the Quicken end or via a patch to the importer or even just a pointer to where in the source I should look. I'm guessing that you must be using 2.2.2, as the ContribX transactions in your QIF file only became supported a few weeks ago. I don't have any ideas for an immediate workaround, but I'm willing to dig through the QIF import code to see if I might be able to find (and possibly fix) the bug. Cheers, Charles ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QIF importer bug in GC 2.2.2 - split transactions
Hi Charles, On Mon, 31 Dec 2007, Charles Day wrote: Andrew, I looked over the QIF file and tried importing it and this is definitely a bug. I seem to recall having the very same problem recently, but I haven't followed up on it because the number of affected transactions was tiny (I think I fixed them by hand). I also encountered bug 114724http://bugzilla.gnome.org/show_bug.cgi?id=114724during my imports which may or may not be related. I think I may also have encountered that one when importing everything but I haven't investigated carefully yet. I've got 18 years worth of Quicken data and ideally I'd like to get it all imported correctly. :-) As a practical matter I will probably have to draw a line somewhere and start manually fixing only accounts that are still active - a somewhat more manageable job. But right now I am still playing the idealist. Bill, if you feel like a walk on the wild side, you could test the notes fix for bug 495219 It's much better for memo fields - thanks! I'd actually already read that bug report but hadn't tried the patch yet. I'm guessing that you must be using 2.2.2, as the ContribX transactions in your QIF file only became supported a few weeks ago. Right. I used your patch in 2.2.1 for some of my earlier attempts at importing and I'm pretty sure this happened in 2.2.1 as well. I updated to 2.2.2 before making the test file and emailing the list. I don't have any ideas for an immediate workaround, but I'm willing to dig through the QIF import code to see if I might be able to find (and possibly fix) the bug. I'd be ever so grateful if you did manage to fix this. As I said, I have literally hundreds of these transactions. I did use Lisp in a class many many years ago but when I look at the code I get lost pretty quickly. I doubt it's just the lack of commenting. :-) Let me know if you do start looking at it and if there is anything I can do to help. - Bill ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [patch] Update README files for Debian dependencies
On Mon, Dec 31, 2007 at 09:50:32AM -0800, Andrew Sackville-West wrote: On Mon, Dec 31, 2007 at 12:26:13PM +0100, Andreas Köhler wrote: Hi Jerry, Am Sonntag, den 30.12.2007, 14:10 -0500 schrieb Jerry Quinn: As I was resolving the dependencies I needed to build gnucash out of svn, I updated the README files somewhat to reflect the current status quo on Debian testing. I tried to capture what I needed both for the automake run as well as configuring and building. I also updated the Debian package version lists in README.dependencies. I checked the versions against stable as well, so I think it's ok. Let me know if anything is amiss. Thanks, I really wonder whether this type of information should only be held at the GnuCash wiki as it tends to become outdated pretty easily. I second that. It should be stored there, but... can it be scraped from there somehow to keep the README's up-to-date? I'm thinking of the poor sap with 28k dialup trying to build it and not having easy access to that list while building. (I know a lot of Debian users work off the install CD's (there's like 20+ of them) and wanting to build when *not* on line). It's a pretty small set of people, I'm sure, but if it could be done with relative ease, why not? apt-get build-dep is an easy way to get most of the dependencies for building from svn on debian. I added this tip to http://wiki.gnucash.org/wiki/Building Hints for building from svn in different distributions would be more likely to stay current on the wiki. I doubt people with svn write access refer to them very often. -- 28 70 20 71 2C 65 29 61 9C B1 36 3D D4 69 CE 62 4A 22 8B 0E DC 3E ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
