close books

Derek Atkins derek at ihtfp.com
Tue Dec 7 12:44:28 EST 2010


On Tue, December 7, 2010 12:33 pm, John Ralls wrote:
>
> On Dec 6, 2010, at 8:07 AM, Derek Atkins wrote:
>
>> Robin Chattopadhyay <robinraymn at gmail.com> writes:
>>
>>>
>>> At a minimum:
>>> * Update the database schema (sqlite, postgres, mysql) to add a column
>>> to
>>> the transactions table called "closing_entry".
>>> * Update the XML schema to add an element called "<trn:closing-entry>".
>>
>> This would be a backwards-incompatible change.  The real way to do this
>> is to use a KVP entry.  Patches welcome (it should be really easy to add
>> this KVP entry).  See the Transaction Notes APIs for how this can be
>> done -- although that uses a string, not a boolean, but the concept is
>> the same.
>>
>
> Do we really want to freeze the database schema for ever? Certainly a
> database change requires as part of the job an upgrade routine so that the
> current Gnucash can read older versions, but why should we box in future
> development (or even bug fixes!) by requiring that 2.2.x can read all
> future databases?

No, and I wasn't proposing that, either.  We *SHOULD* require that 2.2.x
can read anything created by 2.4.x.  However that does NOT follow that
2.2.x should be able to read 2.6.x.  The idea here is that we could add
the read routine in 2.4.x so we can recognize the new structures, but
don't create them until 2.6.x.

> A KVP *is* better, but because it's better architecture: The closing-entry
> mark would apply only to one transaction per year, would only be important
> to one split in that transaction (the income/expense split; one wouldn't
> want to hide the split from equity reports), and wouldn't have any
> applicability to any transactions which don't touch income or expense
> accounts. Something of such limited scope doesn't deserve a column.
>
> Note that the KVP should be on the split, not the transaction, because
> many income/expense reports don't need to look at the whole transaction,
> they just need to total up the credits and debits shown in the splits
> occurring between two dates.

I still believe that the mark should go into the transaction, not the
split.  The reports can decide whether or not to include the split(s) in
their calculations.  And it's very easy to test
split->parent->isClosingEntry().

> Regards,
> John Ralls

-derek




More information about the gnucash-devel mailing list