New data field for invoice object

Alex Aycinena alex.aycinena at
Mon Oct 10 04:41:48 EDT 2011


> ---------- Forwarded message ----------
> From: Geert Janssens <janssens-geert at>
> To: gnucash-devel at
> Date: Sat, 8 Oct 2011 18:23:25 +0200
> Subject: New data field for invoice object
> I'm working on introducing full credit note support in GnuCash [1]. After
> thinking it through for a long time I came to the conclusion I will need to
> add an extra parameter to the invoice object that has to be saved and restored
> from the data file.
> I could use a new kvp, so older versions of GnuCash won't have any problems
> with this. The thing is though that credit notes require changes as such a
> fundamental level in de business logic that older GnuCash versions will
> probably choke on them anyway, or create wrong results. So backward
> compatibility is not really feasible.
> And since kvp's are not nice for the sql backend, I think it will be better to
> use a true field.
> I never added a field, and we have two major backend technologies now. So I'm
> asking some input on how to best proceed.
> Derek suggested on irc to make it an optional field so that if credit notes
> are not used, older versions of GnuCash can still work with the data file. I
> can imagine this with the xml backend, but is such a thing possible with the
> sql backend as well ?
> Geert

When I was considering adding a new field for the split entry-number,
I did a bunch of work to implement it. John's suggestion to use the
'action' field instead, however, is appealing and I will go that way
if my investigations prove that it is feasible (I have been busy and
not able to get to it for a while).

However, I can make all the work I did to implement it available to
you if you like; you can use some, all or none of it as you see fit,
if you decide to implement your new field. It includes adding the new
field, having it included in logging and log replay (which may not
apply to business objects?), and version checking for the xml backend
to prevent prior versions of gnucash from reading the file. It is
fully implemented and tested, but I never committed it.

Let me know if you would like it and I'll send it along with comments.



More information about the gnucash-devel mailing list