[GNC-dev] Auto-incrementing global transaction numbers

[John Ralls]

> On Aug 28, 2021, at 1:10 PM, Thomas A <thomasa88 at gmail.com> wrote:
> 
> On Sat, Aug 28, 2021 at 7:14 PM John Ralls <jralls at ceridwen.us> wrote:
>> 
>> It's not the intended purpose of transaction numbers; that was paper checks, an increasingly rare instrument. A lot of people would find that irritating so it should indeed have an enable button next to the field in settings.
> 
> Interesting! I had to google what checks look like. (For anyone who's
> wondering: https://qph.fs.quoracdn.net/main-qimg-7292757a916da91a0515f729d00bdeeb
> )
> 
>> 
>> There's another option that I think is mutually exclusive to this proposal: Switch num and action. That uses the current account's split action field for the number so that a transaction can have different numbers in different accounts, perhaps the check number in the bank account and the invoice number in the expense account. You'll need to prevent both options being enabled.
> 
> Thanks, that explains the num/action logic.
> 
>> 
>> GNC_ID_TRANS is already in use for something very different indeed. You'll need to invent a different identifier.
> 
> Check!
> 
>> 
>> Unit tests are always good, and yes, it needs to be documented in help, including a new screenshot.
>> 
>> Regards,
>> John Ralls
>> 
> 
> So it sounds like adding a new column, for transaction ID/number,
> would be a more correct implementation. I guess it's not that hard
> logic-wise (copy logic from another column), but it is quite a design
> change (ledger views, dialogs, reports, file format/contents, ...) and
> some code and docs to plow through. Also, users might get confused
> with two "ID" columns displaying by default.
> 
> I now have to possible paths: (a) Extended usage of the Num column,
> with some extra settings check boxes, and (b) adding a completely new
> column.
> 
> Although (b) feels more correct, it probably involves a lot more
> discussion and changing things, if at all accepted. Possibly even a
> file format incompatibility(?).
> 
> What are my chances of actually getting some code accepted/merged for
> alternative (a) and (b), respectively?

I think a is possible, b probably isn't. We do have a mechanism for adding object properties without changing the schema (KVP) but it works best when the extra property is infrequently used. It might be a serious performance problem to use it for every transaction.

I don't see a fundamental design problem with using the num field this way. The UI could be done as a radio group with 
  Use num field as free text, normal use for check numbers
  Use split-action field as num, allows per-split transaction ids
  Use num field for every-transaction serial number
as choices. The extra counter line would be enabled only if the third option was selected.

On the other hand I wonder if this is a feature that fits GnuCash's target user-base. Why would an individual or no-employees sole proprietorship business need it? Why do you need it?

Regards,
John Ralls