Vincent Laisney writes:
Hello,
I am trying to use Gnucash for my personal Finances.
I am french and living in Germany, and I cannot use the Deadkey of my keyboar
in the Field of the Transaction Editor (when I enter new transaction) For
example when I want to type 'ê', I get '^e'. It is not
On Sun, Dec 10, 2000 at 10:40:03PM -0600, Christopher Browne wrote:
On Mon, 11 Dec 2000 11:32:49 +1000, the world broke into rejoicing as
"Phillip Shelton" [EMAIL PROTECTED] said:
How does all of this affect the `closing the books'. If the books are
`close-able' then maybe we do not have
On Mon, Dec 11, 2000 at 01:57:31AM +, Al Snell wrote:
Archives in SQL databases are useful for data mining and OLAP, but
are more costly to store - anm archive file can be dumped onto tape
or just deleted by the user at their convenience...
Keep in mind that in the financial context, you
On Mon, 11 Dec 2000, Bill Gribble wrote:
Keep in mind that in the financial context, you are not-infrequently
asked to do simple "data mining" in the form of any report run over 2,
5, or 10 years of your history. The problem of multiyear reports is
the biggest roadblock to book closing ATM.
On Mon, Dec 11, 2000 at 02:28:15PM +, Al B. Snell wrote:
Yes. I quite like the idea of havnig a "period" number in the transaction
records and, at the increment of each period, creating transactions that
transfer the balance of each account to an equity account, and then
transferring it
On Mon, 11 Dec 2000, Bill Gribble wrote:
Right, but that doesn't help you generate a graph of weekly bank
balances over 5 years. This is a hard problem, and it's one I think
needs to be addressed.
Sure it does...
SELECT SUM(amount),date_to_week_num(date) AS week FROM splits WHERE
On Mon, Dec 11, 2000 at 08:44:58AM +1000, Phillip J Shelton wrote:
This week I will start re-organising the gnumeric functions into better
function class groupings.
Is there anyone who I will need to talk to about with respect to either code
updates they have or the financial library?
I'd
On Mon, 11 Dec 2000 08:13:59 CST, the world broke into rejoicing as
[EMAIL PROTECTED] (Bill Gribble) said:
On Mon, Dec 11, 2000 at 01:57:31AM +, Al Snell wrote:
Archives in SQL databases are useful for data mining and OLAP, but
are more costly to store - anm archive file can be dumped
David Merrill [EMAIL PROTECTED] writes:
So what are the requirements? What exactly do you mean by strong
security?
I'm still working through the requirements. I definitely want all
network traffic encrypted with at least 3-DES or AES (Rijndael). I'd
like to have a flexible authorization
On Sat, 09 Dec 2000 12:05:03 +1100, the world broke into rejoicing as
Robert Graham Merkel [EMAIL PROTECTED] said:
I also agree that a shared financial library would be an excellent
idea.
Is there any other project that might get on board, or should we just
get going and if we start
Any other auditing considerations?
Phill
Christopher Browne wrote:
Also in there is the auditing consideration of "If the period is closed,
and people can't post there, then the past periods of data become `stable.'"
Which is implementable by storing information on what periods of time are
forwarding to the mailing lists ...
Forwarded message:
Organization: trashware
Sender: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: gnucash: QIF import
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Linas,
first of all thank you for your excellent
On Mon, Dec 11, 2000 at 09:01:01AM -0600, Christopher Browne wrote:
What is to be the nature of this "financial library"?
Should there not be some specs of what it is to provide as services?
It is to provide financial analysis functions suitable for building
reports and graphs. Most of
As gnucash is in C, should we look at seeing if it is ok to rewrite in C or
just run with the gnumeric date functions?
Or add another dependency? :-\
Phill
-Original Message-
IMHO date functions are not such a big deal. Believe me, Excel
provides excellent set of date
Phillip J Shelton writes:
Woud also having the date functions in this library be a good thing?
On the face of it, that's not a bad idea. However, the gnumeric
people to some extent have already had their date representation and
functions decided for them (by the desire for Excel
I am not advocating a new dependency. Had enough trouble getting gnumeric to
compile.
-Original Message-
From: Robert Graham Merkel [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 12, 2000 11:15 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Financial library
On 11-Dec-00, 14:43 (CST), Phillip J Shelton [EMAIL PROTECTED] wrote:
Sorry to be dense. Isn't there some way to have the DB store the current
balance with each record? That way the current balence would just be the
current balence from the last record.
One possible problem with this is
David Merrill [EMAIL PROTECTED] writes:
One problem, though. Say the user
jumps to a date in their ledger that is 11 months ago. How do you know
the balance after a given transaction back then, without having to
load the intervening transactions? In an environment with, say, 10,000
On Mon, 11 Dec 2000, David Merrill wrote:
So that means you would retrieve the current balance, and then work
*backwards* from there to calculate running balances in the ledger?
That sounds like it would work with small data sets.
One problem, though. Say the user
jumps to a date in
On Mon, Dec 11, 2000 at 03:12:12PM -0600, Steve Greenland wrote:
On 11-Dec-00, 14:43 (CST), Phillip J Shelton [EMAIL PROTECTED] wrote:
Sorry to be dense. Isn't there some way to have the DB store the current
balance with each record? That way the current balence would just be the
Take your time. I'd rather get a well-thought-out schema in a week
than something hacked together today ;)
-derek
David Merrill [EMAIL PROTECTED] writes:
I said I would work on the database schema today, but my partner and I
decided it was time to put our tree up, before Yule was past. :-)
On Mon, 11 Dec 2000, Bill Gribble wrote:
What I understood your proposal about closing books to be was:
- at book closing time all account balances get rolled
up into a 'closing/opening' balance for the next period.
- expenses/income get transferred to equity.
- old transactions
On 11-Dec-00, 00:18 (CST), Phillip Shelton [EMAIL PROTECTED] wrote:
Yes, that's doubtless one of the design criteria. One, by the way,
that effectively rules out MySQL, as it doesn't do triggers...
A case for a feature request to MySQL?
They don't seem too interested in doing them. The
Phillip Shelton writes:
As gnucash is in C, should we look at seeing if it is ok to rewrite in C or
just run with the gnumeric date functions?
Or add another dependency? :-\
Um, I can't speak definitively but I think we'd all be extremely wary
of adding dependancies to C++ libraries,
On Tue, Dec 12, 2000 at 10:04:49AM +1100, Robert Graham Merkel wrote:
Phillip J Shelton writes:
Would also having the date functions in this library be a good thing?
On the face of it, that's not a bad idea. However, the gnumeric
people to some extent have already had their date
In making the financial functions non gnumeric specific, gnumeric will have
to have a wrapper to add the spread sheet requirements to them so it should
not be too hard to write wrappers for the dates either.
If gnucash is benefiting from numeric with the financial functions then
gnumeric can
On Tue, Dec 12, 2000 at 06:43:17AM +1000, Phillip J Shelton wrote:
Sorry to be dense. Isn't there some way to have the DB store the current
balance with each record? That way the current balence would just be the
current balence from the last record.
Or is that more expensive than I
Woud also having the date functions in this library be a good thing?
Bill Gribble wrote:
On Mon, Dec 11, 2000 at 09:01:01AM -0600, Christopher Browne wrote:
What is to be the nature of this "financial library"?
Should there not be some specs of what it is to provide as services?
It is
On Tue, 12 Dec 2000, Phillip J Shelton wrote:
Sorry to be dense. Isn't there some way to have the DB store the current
balance with each record? That way the current balence would just be the
current balence from the last record.
Or is that more expensive than I realise?
It's a lot of
Thus we need to ask our accountants just what happens at the end of an
accounting period. For I am sure I read somewhere that once an accounting
period is closed then there should be no more changes to that data set. If
an error is found a new transaction in the current period is entered to
-Original Message-
On Mon, 11 Dec 2000, David Merrill wrote:
(grumble) I didn't make myself clear: the point of my proposal about
transferring all the account balances to an equity account
and back again
at period closing was that, to find the current balance,
you'd only need
31 matches
Mail list logo