[GNC-dev] Auto-incrementing global transaction numbers

[John Ralls]

> On Aug 28, 2021, at 10:38 PM, Thomas A <thomasa88 at gmail.com> wrote:
> 
> On Sat, Aug 28, 2021 at 11:45 PM John Ralls <jralls at ceridwen.us> wrote:
>> 
>> 
>> 
>>> 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
>> 
> 
> Then I will go with (a). I will look into that radio setting and see
> if I can come up with some code. I see that there is also a setting
> for enabling "split-action field for num" as default for new books.
> That should translate into the radio being set to the "split-action
> field as num" option when the user creates a new book.
> 
> Regarding fitness, I'm in the process of starting a sole
> proprietorship in Sweden. I heard from an accountant that I need to
> keep a number for each transaction entry (voucher?), to keep a
> connection between receipts and the accounting.
> 
> I actually found the relevant law:
> Swedish Accounting Act (Bokföringslagen), Chapter 5, §7:
> "[...] The voucher shall include a voucher number or other
> identification mark as well as such other information as is necessary
> for the connection between the voucher and the recorded business event
> to be established without difficulty."
> 
> Source: https://www.riksdagen.se/sv/dokument-lagar/dokument/svensk-forfattssamling/bokforingslag-19991078_sfs-1999-1078

GnuCash already meets that requirement: The voucher is the Invoice or Bill; the transaction is the "recorded business event" and GnuCash's posting process establishes the connection between the two. See https://www.gnucash.org/docs/v4/C/gnucash-guide/chapter_bus_features.html and https://wiki.gnucash.org/wiki/GnuCash_Quick_Start_Guide_For_Business_Users.

Regards,
John Ralls