Does GnuCash possess a Journal Entry numbering facility

[Michael Hendry]

On 8 Oct 2014, at 18:58, Derek Atkins <warlord at MIT.EDU> wrote:
> Buddha,
> 
> Buddha Buck <blaisepascal at gmail.com> writes:
> 
>> 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?
> 
> The idea is to have a monotonically increasing "transaction number" so
> you can map the transaction in gnucash to a real-world file.  You can
> easily see if you're missing documentation in the file by seeing that
> you have a gap in your records.
> 
> Using the GUID, while giving your uniqueness, is also random so does not
> give you an easy way to find said gaps.  Nor is there any particular
> order to them.
> 
> You could use the date-posted, date-entered, and GUID combined to create
> a mononotonically increasing transaction id.  That would give you the
> ordering, but you still don't get a way to see gaps of missing
> documentation.

Couldn’t have said it better myself!

In the short term, I can get back quickly to a (sequentially numbered) source document, to check a mismatched figure in a bank or credit card reconciliation.

In the longer run, I can quickly trace a source document as a proof-of-purchase if claiming under warranty, even several years later.

By no means all transactions will have an associated paper document - paying bills online, interest charges on bank accounts (where the only notice is on a bank statement) and scheduled transactions, for example.

It’s essential, though, for _every_ transaction to have a unique (and human-friendly!) number for this method to work.

Michael

> 
> -derek
> 
>> 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.