Would not be surprised if there were even some conflicts in the "set"
> -Original Message-
>
> That means sitting in the somewhat uncomfortable seat named "No, we're
> not assuming that there is a Single Fixed Set of Accounting
> Doctrines."
> [Which, if you see the size of wall covered
On Tue, 12 Dec 2000 12:49:22 EST, the world broke into rejoicing as
David Merrill <[EMAIL PROTECTED]> said:
> On Tue, Dec 12, 2000 at 12:35:45PM -0500, Derek Atkins wrote:
> > David Merrill <[EMAIL PROTECTED]> writes:
> >
> > [snip]
> >
> > > But I do take issue with the argument that period cl
On Wed, Dec 13, 2000 at 06:18:30AM +1000, Phillip J Shelton wrote:
> David Merrill wrote:
>
> > Question: What if you really *need* to go back and correct data in the
> > prior year?
>
> If the change is to the money amount then the book I own says that you make a
> transaction dated at the time
On Wed, Dec 13, 2000 at 06:08:46AM +1000, Phillip J Shelton wrote:
> Derek Atkins wrote:
>
> > David Merrill <[EMAIL PROTECTED]> writes:
> >
> > > aisb, I consider the issue of closing the books and making all
> > > transactions prior to that immutable to be completely orthogonal to how
> > > the
David Merrill wrote:
> Question: What if you really *need* to go back and correct data in the
> prior year?
If the change is to the money amount then the book I own says that you make a
transaction dated at the time you find the error that undoes the wrong data and
then enter another transaction
Derek Atkins wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > aisb, I consider the issue of closing the books and making all
> > transactions prior to that immutable to be completely orthogonal to how
> > the running total is determined. I am proposing a solution to the
> > maintenance of
On Tue, Dec 12, 2000 at 01:09:22PM -0500, Derek Atkins wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> > aisb, I consider the issue of closing the books and making all
> > transactions prior to that immutable to be completely orthogonal to how
> > the running total is determined. I am prop
On 12-Dec-00, 11:35 (CST), Derek Atkins <[EMAIL PROTECTED]> wrote:
> Unfortunately I'm not convinced it completely solves the problem. The
> problem with any checkpointing is that if any transaction changes
> before the checkpoint, then you have to modify all checkpoints that
> have occurred aft
David Merrill <[EMAIL PROTECTED]> writes:
> aisb, I consider the issue of closing the books and making all
> transactions prior to that immutable to be completely orthogonal to how
> the running total is determined. I am proposing a solution to the
> maintenance of running balances that scales we
On Tue, Dec 12, 2000 at 12:35:45PM -0500, Derek Atkins wrote:
> David Merrill <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> > But I do take issue with the argument that period closing, and the
> > transfer of the account balance, is the way to accomplish this. It is
> > certainly one way, but there
David Merrill <[EMAIL PROTECTED]> writes:
[snip]
> But I do take issue with the argument that period closing, and the
> transfer of the account balance, is the way to accomplish this. It is
> certainly one way, but there are others. Let me propose one other way
> for your consideration.
>
> Let
On Tue, Dec 12, 2000 at 05:16:19AM +, Al Snell wrote:
> 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 dat
> -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 onl
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
corre
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 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
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
> t
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
>
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 r
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 i
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 ar
Any way to do what is needed without triggers?
Phill
Steve Greenland wrote:
> 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...
> >
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?
Phill
"Al B. Snell" wrote:
> That was one of three proposals :-)
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 transacti
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.
On Mon, Dec 11, 2000 at 02:35:39PM +, Al B. Snell wrote:
> SELECT SUM(amount),date_to_week_num(date) AS week FROM splits WHERE
> account= GROUP BY week;
>
> That will produce a "total change" for each week, eg a delta series
> instead of a time series, so you have to do some addition in softw
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 dump
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
account
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 i
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 A
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, yo
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 no
On Mon, 11 Dec 2000 15:03:55 +1000, the world broke into rejoicing as
"Phillip Shelton" <[EMAIL PROTECTED]> said:
> > -Original Message-
> > 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 af
> -Original Message-
> Different industries may have some particular legal requirements; that
> will generally surround there being a need to specifically _preserve_
> information for some number of years, as opposed to needing
> to _get rid_
> of data at the end of the year.
True. I wa
> -Original Message-
> 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 to read the last 10
> years wo
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 to read the last 10 years worth of
> data in at once?
>
> Will the c
These should still be able to be browsed? And what about being able to read
old archived files with new GnuCash?
Phill
> -Original Message-
> > Will the closing of the books be easier or harder with a DB?
>
> I favour the "creating a saved GnuCash file" (in XDR format?
> :-) method of
>
On Mon, 11 Dec 2000, Phillip Shelton wrote:
> Will the closing of the books be easier or harder with a DB?
Depends how you want to handle it. You could create archives as saved
GnuCash files, flush the transaction logs, then create initial equity
transactions to set up initial balances... or put
How does all of this affect the `closing the books'. If the books are
`close-able' then maybe we do not have to read the last 10 years worth of
data in at once?
Will the closing of the books be easier or harder with a DB?
Phill
___
gnucash-devel mai
39 matches
Mail list logo
