> On Aug 28, 2021, at 10:38 PM, Thomas A <[email protected]> wrote: > > On Sat, Aug 28, 2021 at 11:45 PM John Ralls <[email protected]> wrote: >> >> >> >>> On Aug 28, 2021, at 1:10 PM, Thomas A <[email protected]> wrote: >>> >>> On Sat, Aug 28, 2021 at 7:14 PM John Ralls <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
