Does GnuCash possess a Journal Entry numbering facility

[Buddha Buck]

If I recall correctly, the existing gnucash data file format for
transactions includes a unique transaction id, a date posted, and a
datetime entered, while the individual splits can include a datetime
reconciled.

Not all these fields are exposed in the UI, but they probably are in the
API.

What purpose would be served by a new journal entry counter that couldn't
be served by these?

"Choosing to export the JE# field along with its Date permits searching for
subsequent JEs that predate a
reconciled balance so as to show the "offending" entry." could be done by
looking for searching for transactions which have a date-posted before the
reconciliation date, and a date-entered after the reconciliation date.

The unique transaction ID already serves as a unique identifier for a
transaction.

Or is there a difference between a journal entry and a transaction I'm not
aware of?


On Wed, Oct 8, 2014 at 1:14 PM, Derek Atkins <warlord at mit.edu> wrote:

> Michael Hendry <hendry.michael at gmail.com> writes:
>
> >> I'm not convinced it would be a MAJOR alteration.  You would need to:
> >>
> >> 1) add the data field to the Transaction object, and figure out how to
> >>   best store it.
> >
> > Wouldn’t that just happen automatically when the (enhanced) object is
> > stored? (shows how much I know!).
>
> Maybe, maybe not.  Depends how you store it.  Care must be taken to make
> sure you don't make the data file unloadable by older versions of
> gnucash, or worse, silently lose the data on older versions.
>
> >> 2) Store a global counter (we already have space for these)
> >
> > There would also need to be a mechanism for starting the numbering at
> > a user-specified number.
>
> This is just a UI nicety.  The counter mechanisms already exist, which
> is the harder part.
>
> >> 3) Use the counter every time a transaction gets posted (well, the first
> >>   time) to fill in the field
> >
> > Yes, it would be necessary to distinguish between a newly created
> > Transaction object and one which is being edited.
>
> That's easy enough -- when you commit the transaction just check if it
> already has a number and, if not, grab the next from the counter and
> store it.
>
> >> 4) (optional) add a way to view the value from the register.
> >
> > Yes, I would require this, so that I can mark the input document
> appropriately.
> >
> >>
> >> Note:  what do you do if you later delete a transaction?
> >
> > I’d be inclined to deal with this with a Contra Entry, with a text
> > reference to the transaction number of the transaction which is to be
> > reversed. I’d probably also edit the original transaction to say it
> > had been reversed, with a reference to the Contra Entries sequence
> > number.
> >
> >>
> >
> > You’ve whetted my appetite, just a little…
>
> :)
>
> > Michael
>
> -derek
>
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord at MIT.EDU                        PGP key available
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>