Missing reconcile status

[Diane Trout]

On Thu, Mar 02, 2000 at 01:01:45PM -0800, Dave Peticolas wrote:
> > I think I found a minor bug. Under some circumstances in the register
> > window the field showing the reconciliation status for the debits
> > ended up getting formatted outside of the box. (I briefly hacked
> > around it by telling GTK to give extra space from resizing to the
> > child window).
>  
> What are those circumstances? Can you give a way to duplicate it?

Yes... It appears that when there's enough data to need a scroll bar
in one of the debit or credit panes it ends up hiding the reconcile
status field.

Looking at the way it's behaving a reasonable guess might be it's
calculating the sizes of the text fiels before the scroll bar is
added?

diane

 PGP signature

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: Missing reconcile status

[Dave Peticolas]

> 
> --bg08WKrSYDhXBjb5
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Thu, Mar 02, 2000 at 01:01:45PM -0800, Dave Peticolas wrote:
> > > I think I found a minor bug. Under some circumstances in the register
> > > window the field showing the reconciliation status for the debits
> > > ended up getting formatted outside of the box. (I briefly hacked
> > > around it by telling GTK to give extra space from resizing to the
> > > child window).
> > =20
> > What are those circumstances? Can you give a way to duplicate it?
> 
> Yes... It appears that when there's enough data to need a scroll bar
> in one of the debit or credit panes it ends up hiding the reconcile
> status field.
> 
> Looking at the way it's behaving a reasonable guess might be it's
> calculating the sizes of the text fiels before the scroll bar is
> added?

I'm not seeing this error. What version of gtk are you using?

Are you compiling from CVS? I have some patches to that window
that may fix the problem.

dave

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

cvs

[Dave Peticolas]

I currently can't get to the cvs server, so cvs
may not be updated tonight :(

I'll try again later tonight and, if that doesn't
work, tomorrow.

dave

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

QIF troubles

[David Bobroff]

Rob Browning <[EMAIL PROTECTED]> wrote:

>Well, if you can hold off for a bit (not quite sure what the timetable
>is, but I would guess about a week or so), Bill's making great
>progress on the QIF front.  I suspect you'll have *much* better
>results using his code once it's available.

I'll be patient.

>Plus, you'd make a good
>guinea pig :>

Fine, just as long as I get to have one of those cool exercise wheels and I
get to drink from one of those inverted water bottles with the steel ball
in the end of the spout.

Thanks,

David 

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: QIF Import Comments

[Christopher Browne]

On Thu, 02 Mar 2000 13:38:56 CST, the world broke into rejoicing as
David A Fenyes <[EMAIL PROTECTED]>  said:
> On Thu, 02 Mar 2000, you wrote:
> > On 01 Mar 2000 09:10:10 CST, the world broke into rejoicing as
> > Bill Gribble <[EMAIL PROTECTED]>  said:
> > > Christopher Browne <[EMAIL PROTECTED]> writes:
> > > > The next step is to create a dialog that would be used to verify
> > > > each account based on the scores.  My vision is that it would look
> > > > rather like the following:
> > > 
> 
> It would be nice if there is an "import" selection in the register window
> itself, which would place the given account at the top of the "guess"
> algorithm.

Ah, yes.  That is indeed a very good observation.  

This makes the selection of the "account-to-which-all-this-stuff-goes" an
explicit choice, visible to, and controllable by, the user.  Definitely a
good thing.
--
Actually, typing random  strings in the Finder does  the equivalent of
filename  completion.(Discussion  in  comp.os.linux.misc   on  the
intuitiveness of commands: file completion vs. the Mac Finder.)
[EMAIL PROTECTED] - 

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: QIF Import Comments

[Bill Gribble]

Christopher Browne <[EMAIL PROTECTED]> writes:
> David A Fenyes <[EMAIL PROTECTED]>  said:
> > It would be nice if there is an "import" selection in the register window
> > itself, which would place the given account at the top of the "guess"
> > algorithm.
> 
> Ah, yes.  That is indeed a very good observation.  

For single-QIF imports, that seems to be the best guess.  However, in
general I think you can do a better job of matching up Quicken
single-entry transactions with each other by a allowing multiple
simultaneous QIF file imports and resolving them into splits before
stuffing them into the engine.  In that case, you don't really have
"The QIF File" to match with "The Selected Account".

It's my perception that a large fraction of QIF files use the "Opening
Balance" kludge to specify the account name (true?) and having a
persistent mapping of QIF account names to GNUcash account IDs will
make it easy to guess correctly the first time.

In any case, just knowing what account the transactions are with
respect to doesn't solve all your account-matchup problems; you
still need to match the destination accounts and categories 
to gnucash accounts.

I think part of the problem with the current import code is that it's
a 1-step process... you pick a file, and then suddenly there are new
transactions everywhere.  

I'm trying to separate this into a multistage process, so you can see
what's going to happen and have a chance to tweak the importing
process before it modifies your gnucash accounts.  The first step is
to load and parse multiple QIF files, building a "loaded files" list
in the dialog.  For each file, you can specify the account, currency,
radix format, and date format, or allow them to be autodetected
(except the currency... that has to be specified).  Autodetection
works quite well now.  After loading, if the autodetection doesn't
work (for example, there's no Opening Balance transaction to give the
account name) you can modify any of that stuff before moving on.

In the next tab of the notebook, there's a map of QIF accounts (parsed
from the QIF files you've loaded, either in Account records or from
the "L" fields of transactions) to Gnucash accounts.  The initial
mapping is guessed.  Right now the guesser is stupid but I'm planning
on something using persistent mappings so once you tell it something
it will get it right in the future.  If you don't like the guess,
clicking on that row pops up a GtkTree-based account picker.  I
haven't yet included the ability to create a new account in the
account picker, but it shouldn't be hard.

The next tab of the notebook does the same thing, but for QIF
categories.  Since there are generally a lot of these, I am thinking
about only displaying categories that are mentioned in one or more
transactions in the file set.  I already sort them in the display by
the number of transactions that reference them, which seems to do
pretty much the same thing. Thoughts?

The last tab of the notebook right now is just a text string that
says, "this is an important problem, don't f*** it up."  The label on
the tab is "transactions" and the problem is how to do really the
right thing about folding single-entry QIF transactions into splits.
For initial imports (my immediate goal) it's not such a big deal...
in a set of QIF files, you either find a "match" for a transaction
from the other end or you don't, and after performing due diligence in
a mark and sweep you do your best.  The problem comes when you are
importing QIF files that you got from your bank that represent a
partial list of transactions, some of which are already in your
records and some which aren't.

My idea is to somehow red-flag fishy transactions (ones that could be
duplicates or half-duplicates), and somehow present these for
inspection.  It's going to be somewhat time-consuming and definitely
heuristic to do a full check for duplicates, so my initial feeling was
that I'd make that a "Verify" button on the last dialog page, which
would let you either detect and do something about this case or just
ignore it and click on the big OK that sucks everything into the
engine.

I know this sounds complicated, but it's really not more than I think
is needed to solve the problem reliably.  The idea is that once you
have established mappings they will be remembered, so you can just
ignore the back pages of the dialog and it's 3 clicks to import the
file.

Any thoughts? 

b.g.






--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Notification: incoming/114

[bugs]

Gnucash BugTrack notification

new message incoming/114

Message summary for PR#114
From: [EMAIL PROTECTED]
Subject: GnuCash Transfer field in register
Date: unknown
0 replies   0 followups

> ORIGINAL MESSAGE FOLLOWS <

Received: (qmail 26483 invoked from network); 3 Mar 2000 15:36:02 -
Received: from localhost (127.0.0.1)
  by localhost with SMTP; 3 Mar 2000 15:36:02 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: GnuCash Transfer field in register

Full_Name: Dan Watson
Version: 1.30
GUI: gnucash-gnome
OS: Linux RedHat 6.0
Submission from: (NULL) (198.110.16.102)


When you either click or tab into the transfer field on the register the program

locks up and the only way out is to kill the process.


--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: Missing reconcile status

[Diane Trout]

On Fri, Mar 03, 2000 at 12:42:17AM -0800, Dave Peticolas wrote:
> > Looking at the way it's behaving a reasonable guess might be it's
> > calculating the sizes of the text fiels before the scroll bar is
> > added?
> 
> I'm not seeing this error. What version of gtk are you using?

gnucash.gnome is linked to 
libgtk-1.2.so.0 (which is actually libgtk-1.2.so.0.5.2
libgdk-1.2.so.0 (libgdk-1.2.so.0.5.2)

(Basically I'm using the latest version of stuff in debian potato.)

> 
> Are you compiling from CVS? I have some patches to that window
> that may fix the problem.

Yep... I even deleted my tree and rebuilt... though I'm using the
debian makefile.

The other bit is I'm using gtk themes, and the behavior did seem to
change depending on the theme. Originally I was using gtk-step, and
the reconcile field was completely invisible. Now I switched over to
coolness, and you can tell there's a little bit of a field that's
under the scroll bar. So it might be dependant on themes...

After thinking of that I tried several other themes and it didn't
help... It could also be the fonts installed on my system.
 PGP signature

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: QIF Import Comments

[David A Fenyes]

On Fri, 03 Mar 2000, you wrote:
> Christopher Browne <[EMAIL PROTECTED]> writes:
> > David A Fenyes <[EMAIL PROTECTED]>  said:
> > > It would be nice if there is an "import" selection in the register window
> > > itself, which would place the given account at the top of the "guess"
> > > algorithm.
> > 
> > Ah, yes.  That is indeed a very good observation.  
> 
> For single-QIF imports, that seems to be the best guess.  However, in
> general I think you can do a better job of matching up Quicken
> single-entry transactions with each other by a allowing multiple
> simultaneous QIF file imports and resolving them into splits before
> stuffing them into the engine.  In that case, you don't really have
> "The QIF File" to match with "The Selected Account".
> 

I suspect that the most common import scenario will be downloaded transactions
from the internet, which will include transactions involving only one account,
with no label, if my bank is any indication (B of A).  I'm talking, of course,
about imports after the initial wave of imports (from dumping quicken files
before dumping quicken), which will likely benefit from a fancy algorithm, as
will people trying to episodically synchronize quicken and gnucash.  

> In any case, just knowing what account the transactions are with
> respect to doesn't solve all your account-matchup problems; you
> still need to match the destination accounts and categories 
> to gnucash accounts.
> 

This is true.  It would be nice to create categories automatically (I think
this is already done.)  That way, Quicken-generated QIF files tend to be
imported quickly, and we don't have to retype in all our expense/income
accounts.  

David.
-- 
David Fenyes  --  [EMAIL PROTECTED]

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: QIF Import Comments

[David A Fenyes]

On Fri, 03 Mar 2000, you wrote:

> I'm trying to separate this into a multistage process, so you can see
> what's going to happen and have a chance to tweak the importing
> process before it modifies your gnucash accounts.  

Your plan as outlined sounds really nice.

  The problem comes when you are
> importing QIF files that you got from your bank that represent a
> partial list of transactions, some of which are already in your
> records and some which aren't.
> 
> My idea is to somehow red-flag fishy transactions (ones that could be
> duplicates or half-duplicates), and somehow present these for
> inspection.  It's going to be somewhat time-consuming and definitely
> heuristic to do a full check for duplicates, so my initial feeling was
> that I'd make that a "Verify" button on the last dialog page, which
> would let you either detect and do something about this case or just
> ignore it and click on the big OK that sucks everything into the
> engine.

Yes, you hit the nail on the head.  This would be analagous to the "approve"
window you get when you download transactions from the financial institution
using Quicken.  Perhaps you could also memorize that a given imported
transaction matched previously to a given manually entered transaction, and
use that info to better guess the destination account?

David
-- 
David Fenyes  --  [EMAIL PROTECTED]

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: A couple of feature ideas...

[linas]

It's been rumoured that Dave Peticolas said:
> 
> > 
> > For example:
> > 
> > Business Income:Consulting/Acme
> > Business Office Expense:Copies/Acme
> > Business Office Expense:Hardware/Acme
> > 
> > I suppose it might work if the reporting modules knew that the stuff
> > after the / was a class and knew to ignore it in some cases, and match=20
> > it in others.
> > 
> > Though then you still have the annoyance of creating new accounts for
> > each project.
> 
> Ohh, I read your email wrong. My brain changed the '/' to a ':'.

At some point, we should add support for projects, although I really
haven't thought about how to do that correctly.

--linas

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: Check printing

[linas]

It's been rumoured that Christopher Browne said:
> e) Decide that the above approach sucks, as it requires Yet Another
> Tool in the flow.

The raw post-script idea for check printing sounds good.  KISS.
Keeps it simple.

--linas

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: gnucash & latest lesstif trouble

[linas]

It's been rumoured that [EMAIL PROTECTED] said:
> 
> I just installed the gnucash 1.2.5 rpm on my redhat 6.0 intel linux box.
> But it wont start:
> ~ $ gnucash
> gnucash: error in loading shared libraries: libXm.so.1: cannot open shared object 
>file: No such file or directory
> 
> But I have the latest lesstif (0.89.9) installed.
> ~ $ rpm -q -l lesstif
> .
> .
> .
> /usr/X11R6/LessTif/Motif1.2/lib/libXm.so.1

Try ldconfig -p |grep libXm

if that shows nothing, then hand-edit
/etc/ld.so.conf and add /usr/X11R6/LessTif/Motif1.2/lib to it
and then run ldconfig (without the -p flag)

That should cure it.

> Whats wrong?
> I tried 1.3.0 but it locked up while entering data into a register. So I thought I'd 
>back off to 1.2.5.

Ugh. Maybe there's a 1.3.1 soon 

--linas

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

cvs 2000-03-01

[Dave Peticolas]

CVS has been updated.

Bug Status Changes:

 To fixed: 112


New Stuff:

 + Yannick LE NY's french translation file.

 + Temporary fix for bug #110

 + Removed C-a and C-d and account add and delete shortcuts (#112).

 + Reconcile window comes up with at least 8 rows displayed. The
   scrollbars are always shown to make the reconcile column width
   more uniform.

 + The options dialog runs all the displayed strings through gettext.

 + There is new guile functionality for translating strings.
   The guile functions gnc:gettext and gnc:_ both return the
   translated version of a string, if it exists, or the original
   string otherwise.

   Also, if (gnc:debugging?) is true, any strings which could be
   *potentially* displayed to the user should be registered with
   gnc:register-translatable-strings. When in debug mode, there
   is a menu item in the extensions menu which saves all the
   registered strings to a file suitable for gettext parsing.

   This already happens for all options, both global and report,
   and for menu items. The other strings used in individual reports
   still need to be registered when the report is loaded and the
   strings which are actually used when the report is run need to
   be passed through gnc:_.

   As a hack, if (gnc:debugging?) is true, gnc:gettext and gnc:_
   will also register the string. However, since not all strings
   may be used in a given run of a report, it's best to register
   them all explicitly.

 + The translatable strings in the options and menu items which
   were found with the above method have been added to the file
   gnucash/po/guile_strings, which is now used in generating po
   files. Both fr.po and de.po have been merged with this file.

   This added about 200 strings; translators, have fun!


dave

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Notification: incoming/114

[bugs]

Gnucash BugTrack notification

jcollins moved PR#114 from incoming to gnucash-gnome
Message summary for PR#114
From: [EMAIL PROTECTED]
Subject: GnuCash Transfer field in register
Date: unknown
0 replies   0 followups

> ORIGINAL MESSAGE FOLLOWS <

Received: (qmail 26483 invoked from network); 3 Mar 2000 15:36:02 -
Received: from localhost (127.0.0.1)
  by localhost with SMTP; 3 Mar 2000 15:36:02 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: GnuCash Transfer field in register

Full_Name: Dan Watson
Version: 1.30
GUI: gnucash-gnome
OS: Linux RedHat 6.0
Submission from: (NULL) (198.110.16.102)


When you either click or tab into the transfer field on the register the program

locks up and the only way out is to kill the process.


--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

SWIG

[Jeremy Collins]

Is SWIG required to build the Gnome version these days?  I thought the
only need for it was because of the perl bindings.

-- 
Jeremy Collins
LinuxMall.com
[EMAIL PROTECTED]

--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: SWIG

[Dave Peticolas]

> 
> Is SWIG required to build the Gnome version these days?  I thought the
> only need for it was because of the perl bindings.

I think it is needed, but we really ought to allow building
without it. To clarify, I believe the build process will fail without
it, but SWIG is not actually used in building the gnome binary.

dave


--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Notification: incoming/115

[bugs]

Gnucash BugTrack notification

new message incoming/115

Message summary for PR#115
From: [EMAIL PROTECTED]
Subject: QIF Import with Split Transactions
Date: unknown
0 replies   0 followups

> ORIGINAL MESSAGE FOLLOWS <

Received: (qmail 21855 invoked from network); 4 Mar 2000 00:23:10 -
Received: from localhost (127.0.0.1)
  by localhost with SMTP; 4 Mar 2000 00:23:10 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: QIF Import with Split Transactions

Full_Name: Robert Ellman
Version: 1.3.0 beta
GUI: gnucash-gnome
OS: Linux - Red Hat 6.?
Submission from: (NULL) (209.144.169.10)


Importing from Quicken v3 (which was running under Wine). 
Transactions which are part of a split get duplicated.

For example, if a check was written that was for a loan,
the transaction in the checking acct has "Loan Account" and 
"Loan Interest" as categories.  When importing the QIF from
the "Loan Account" and then from the "Checking Account" the 
transaction shows up twice.


--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Notification: incoming/116

[bugs]

Gnucash BugTrack notification

new message incoming/116

Message summary for PR#116
From: [EMAIL PROTECTED]
Subject: QIF Import Dates past 1/1/2000
Date: unknown
0 replies   0 followups

> ORIGINAL MESSAGE FOLLOWS <

Received: (qmail 22257 invoked from network); 4 Mar 2000 00:25:29 -
Received: from localhost (127.0.0.1)
  by localhost with SMTP; 4 Mar 2000 00:25:29 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: QIF Import Dates past 1/1/2000

Full_Name: Robert Ellman
Version: 1.3.0 beta
GUI: gnucash-gnome
OS: Linux Red Hat 6.?
Submission from: (NULL) (209.144.169.10)


When importing from a QIF file (exported using Quicken v3 running under Wine)
all transactions that were dated past 12/31/1999 show up as 12/31/1969.  I don't
know if this is a gnucash problem or a QIF format problem because Quicken v3
sets a default end date of 12/31/1999 within the export dialog.



--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]

Notification: incoming/117

[bugs]

Gnucash BugTrack notification

new message incoming/117

Message summary for PR#117
From: [EMAIL PROTECTED]
Subject: Feature Request - Control Order Of Accounts
Date: unknown
0 replies   0 followups

> ORIGINAL MESSAGE FOLLOWS <

Received: (qmail 22733 invoked from network); 4 Mar 2000 00:27:42 -
Received: from localhost (127.0.0.1)
  by localhost with SMTP; 4 Mar 2000 00:27:42 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Feature Request - Control Order Of Accounts

Full_Name: Robert Ellman
Version: 1.3.0 beta
GUI: gnucash-gnome
OS: Linux Red Hat 6.?
Submission from: (NULL) (209.144.169.10)


It would be nice to be able to control the order of accounts that show up in the
account list window.  Either sorting by type (i.e. Checking, Credit Card,
Expense, Asset, etc) or at least by name (Alphabetically).

As it stands now, after importing a bunch of QIF files, I've got to search
around for  accounts which Quicken had previously grouped together.


--
Gnucash Developer's List 
To unsubscribe send empty email to: [EMAIL PROTECTED]