Re: QIF format ?

[Rob Browning]

Hendrik Boom <[EMAIL PROTECTED]> writes:

> Some kind of scripting seems appropriate.  But maybe I should just
> use a Perl script befire importing?

Having some kind of hooks would probably be nice in there, but I
haven't thought about it enough to know what would be most useful.  It
seems like you might want a way to create "filters", and a way to
attach them to different input sources.

Just thinking out loud here, and presuming a lot of things that don't
exist:

  (define (my:filter-swap-memo/desc qif-imported-data)
(let* ((qd qif-imported-data)
   (old-memo (assq-ref qd 'memo)))
  (assq-set! qd 'memo (assq-ref qif-imported-data 'description))
  (assq-set! qd 'description old-memo)
  qd))

  (gnc:add-qif-import-filter 'megacorp-visa
 my:filter-swap-memo-transaction)

or something.  Having a flexible infrastructure for the "incoming
matching" process would be good too.

There will almost certainly be cases where you can make the matching
process much more accurate given some knowledge about your particular
sources.

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

multibyte character display, take 2 (long)

[Shimpei Yamashita]

So here are what I've discovered so far regarding display of
multibyte (specifically Japanese) characters in GnuCash:

* For the "duh!" award of the day, the register displays everything in
Helvetica, including Japanese multibyte texts, because DEFAULT_FONT and
ITALIC_FONT are hard-coded to be Helvetica. Re-hard-coding them to be
Japanese fonts fixed that problem, but I'm not so brazen as to offer that
patch for CVS inclusion. Clearly something needs to be done about this, I'm
just not sure what. If there is a way to get the locale-specific default
font/fontset in Gtk/Gnome, I suppose the DEFAULT_FONT and ITALIC_FONT
macros could be replaced by that.

Interestingly, Japanese characters do show up fine in the drop-down list that
lists all the accounts. The result from the selection is still mangled,
though.



* The lower right hand corner (asset/profit) doesn't display multibyte
characters--namely, the Yen symbol--correctly because it also insists on
using Helvetica. Puzzlingly enough, this can be fixed by commenting out
line 863 of src/gnome/dialog-utils.c (in gnc_set_label_color):

 gtk_widget_set_style(GTK_WIDGET(label), style);

although this keeps the total from turning red when the balance is negative.
What this seems to suggest is that the font setting is fine until you run this
function, upon which some evil monolingual routine resets the font to
Helvetica!

I've also discovered, however, that running

 style->font = gdk_fontset_load(SOME_JAPANESE_FONT);

any time before gtk_widget_set_style (including during initialization of the
label widget) also "solves" the problem--so gtk_widget_set_style doesn't
*always* reset the font! Now I'm completely lost.

BTW, I tried to get some documentation on the GtkStyle class, but the styles
section of the online Gtk reference manual is one of the few sections that are
still unfinished. Murphy's law strikes again.



* Finally, XIM (X input method--a method that allows non-Roman-alphabet
people to enter their scripts by translating keyboard input to native
script) continues not to work for the register window. Someone did
email me and tell me they might be able to get it to work, which would
be great, as I'm still getting up to speed on Gtk programming.


I'm using gnome-libs-1.0.61 and gtk+-1.2.7, BTW, if that's important.

-- 
Shimpei Yamashita   

Re: QIF format ?

[Hendrik Boom]

> Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> > I am thinking in terms of a "plugin" to reformat the "memo"
> > information into the fields, like cheque number and Payee, which are
> > more appropriate.
> 
> Could you clarify this last part a bit?  Have you observed the QIF
> memo field to be used in place of the existing QIF check number and
> payee fields?  
> 
> Thanks,
> Bill Gribble
> 
While we're opn the subkect, my bank puts the transaction date into the
memo field on credit card statements.  The cleared date is in the
date field.

^
M11/1/99
D11/4/99
PCOMMUNICATIONS ACCESSI MONTREAL PQ 
T-40.20
N
^

Also, note the placement of foreign currency amounts in the P line.
(for me, US is foreign, and Canadian is domestic).

^
M11/7/99
D11/8/99
PANNABELLE`S BAR + BISTRO SAN FRANCISCO CA US  AMT =   30.44US
T-45.46
N
^

Some kind of scripting seems appropriate.
But maybe I should just use a Perl script befire importing?

-- hendrik.

Re: Menubar headings missing

[Dave Peticolas]

> Dave Peticolas writes:
>  > > > Dave Peticolas writes:
> 
>  > > > Now that I don't understand. I don't believe we are using
>  > > > curses anywhere in GnuCash, at least this is the first I've
>  > > > heard of it :)
>  > > 
>  > > guile was probably compiled against curses rather than termcap.
>  > 
>  > Yes, I think you've hit on it. So it would seem that guile-config
>  > did not return the correct link-time arguments.
> 
> Yes, guile-config link returns
> 
>   -L/usr/local/lib -lguile -ldl -lsocket -lnsl -lm  
> 
> It's gnucash's configure which adds "-lreadline" 
> 
>   # If readline exists, just assume that guile needs it.  It probably does.
>   AC_CHECK_LIB(readline, readline)
> 
> but without checking for any dependencies of libreadline itself.

Ok, my guile-config correctly reports the readline dependency.
Try this: just delete the AC_CHECK_LIB(readline, readline) and
see if that works (without linking with curses).

dave

Re: Menubar headings missing

[Keith Refson]

Dave Peticolas writes:
 > > > Dave Peticolas writes:

 > > > Now that I don't understand. I don't believe we are using
 > > > curses anywhere in GnuCash, at least this is the first I've
 > > > heard of it :)
 > > 
 > > guile was probably compiled against curses rather than termcap.
 > 
 > Yes, I think you've hit on it. So it would seem that guile-config
 > did not return the correct link-time arguments.

Yes, guile-config link returns

  -L/usr/local/lib -lguile -ldl -lsocket -lnsl -lm  

It's gnucash's configure which adds "-lreadline" 

  # If readline exists, just assume that guile needs it.  It probably does.
  AC_CHECK_LIB(readline, readline)

but without checking for any dependencies of libreadline itself.

Keith Refson

 
-- 
Dr Keith Refson,"Paradigm is a word too often used by those who would
Dept of Earth Sciences  like to have a new idea but cannot think of one." 
Parks Road,  -- Mervyn King, Deputy Governor, Bank of England
Oxford OX1 3PR, UK
Keith.Refson@   Tel: 01865 272026
 earth.ox.ac.uk Fax: 01865 272072

Re: gnucash contribution

[tboldt]

Richard Wackerbarth wrote:

> On Thu, 18 May 2000, Bill Gribble wrote:
> > Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> > > I would handle this by having the sample setups in QIF (or a native
> > > gnucash) format and importing those files as needed. There is no
> > > point in creating new mechanisms. However, it might be appropriate
> > > to have a special "button" in the setup wizard to script the import.
> >
> > Having a skeleton of accounts in an .xac file is something that we've
> > talked about for a while.
> >
> > However, it doesn't solve the "I'm a completely new user" problem.
> > You really want a "walk through" which says, "do you have a bank
> > account?  what bank?  what's the account number?"  etc.  I think a
> > skeleton of standard accounts is a good thing but not enough in the
> > long run.
>
> I agree.
>
> I was thinking more along the lines of the income/expense part of it with a
> few dummy asset accounts that the user could mimick.
>
> Having a "setup wizard" to lead the user in setting up his asset accounts is
> even better (and more work).
>
> Actually, I see two levels:
>   Do you have a(nother) bank account?
>   Do you have a(dditional) credit card(s)?
>   Do you have any stocks?
>   etc.
>
> and
>   What is the name of the bank?
>   When did you open the account?
>   Does the bank pay interest on your deposits?
>   etc.

The very first thing I did when starting to use gnucash a few weeks ago was to
set up all of my accounts - nothing in them. I then saved this as a totally
separate file. Whenever I add an account I change this 'skeleton' account file
to track my 'real' account file. Creating a skeleton account file isn't a big
deal and I didn't understand why this wasn't done a long long long time ago by
the gnucash developers - after all they are users also.

Re: gnucash 1.3.7 bugs.

[Jon A. Christopher]

On Wed, 17 May 2000, Rob Walker wrote:

> 
> > On 16 May 2000 16:36:00 -0500, Bill Gribble
> > <[EMAIL PROTECTED]> said:
> 
> Bill> "Jon A. Christopher" <[EMAIL PROTECTED]> writes:
> 
> >> Eliminating single-entry would be a mistake IMHO.  Who wants to
> >> learn a new system of accounting just to balance their checkbook?
> 
> Bill> But my question was, WHAT is it about double-entry that's new?
> Bill> It doesn't change the way you use gnucash AT ALL, except that
> Bill> you are required to have a "category" for every transaction.
> Bill> Are you seriously saying that that's too much for you?
> 
> Maybe there could be an option which was "default all categories to
> misc", which would keep people from having to do the "categorize every 
> transaction" thing when they don't want to.

I still think things are fine the way they are.  Why change it?

-Jon

-- 
Dr. Jon A. Christopher  / [EMAIL PROTECTED] |  Project URLs:
Department of Biochem./Biophys./  spock: http://quorum.tamu.edu/spock
Texas A&M University MS-2128  / lesstif: http://www.lesstif.org/
College Station, TX, 77843   / personal: http://quorum.tamu.edu/jon

Re: QIF format ?

[Richard Wackerbarth]

On Fri, 19 May 2000, Bill Gribble wrote:
> Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> > Please provide short samples of each format. I am interested in the
> > information that identifies the transaction as well as the
> > differences in the formats.
> >
> > I am thinking in terms of a "plugin" to reformat the "memo"
> > information into the fields, like cheque number and Payee, which are
> > more appropriate.
>
> Could you clarify this last part a bit?  Have you observed the QIF
> memo field to be used in place of the existing QIF check number and
> payee fields?

Yes. (At least some) Online banking generates valid, but incompletely parsed 
entries. Transaction identification is encoded.

Re: QIF format ?

[Bill Gribble]

Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> Please provide short samples of each format. I am interested in the
> information that identifies the transaction as well as the
> differences in the formats.
> 
> I am thinking in terms of a "plugin" to reformat the "memo"
> information into the fields, like cheque number and Payee, which are
> more appropriate.

Could you clarify this last part a bit?  Have you observed the QIF
memo field to be used in place of the existing QIF check number and
payee fields?  

Thanks,
Bill Gribble

Re: QIF format ?

[Richard Wackerbarth]

On Fri, 19 May 2000, Hubert Figuiere wrote:

> > Individually, we each have access to only a small set of data sources.
> > However with your help, we can collectively obtain a much larger sample.
>
> Basically, there are only 2 different files:
>
> one for Money and one for quicken.
> The only differences between each files are that Money file dates are
> generated with 4-digits years while Quicken file only use two.
>
> I can provide the sample files :=)

Thanks.

If those are the only differences, I wonder why you were given more than two 
choices.

Please provide short samples of each format. I am interested in the 
information that identifies the transaction as well as the differences in the 
formats.

I am thinking in terms of a "plugin" to reformat the "memo" information into 
the fields, like cheque number and Payee, which are more appropriate.

Re: QIF format ?

[Hubert Figuiere]

According to Richard Wackerbarth <[EMAIL PROTECTED]>:
> On Thu, 18 May 2000, Hubert Figuiere wrote:
> > I can do this, but this banking informations are *confidential* (they are
> > mine :=)).
> 
> Our interest is in the form of the entries rather than their values.
> You should feel free to disguise account numbers, Payee names, and monetary 
> amounts. However, if you do so, please watch that you don't change the format 
> of the entries. Also watch for fields that are arithmetically related.
> 
> As for the situation involving different export formats, our interest is only 
> in the differences. If you can locate the differences for us, a single 
> example entry would be quite enough.
> 
> Individually, we each have access to only a small set of data sources. 
> However with your help, we can collectively obtain a much larger sample.

Basically, there are only 2 different files:

on for Money and one for quicken.
The only differences between each files are that Money file dates are generated
with 4-digits years while Quicken file only use two.

I can provide the sample files :=)

Hub