On Sun, Aug 29, 2021 at 5:49 PM John Ralls <[email protected]> wrote: > > > > > 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 >
And Bill ID and Invoice ID are the ID counters (and they are prefixable using settings for the Counters). I should have read the manual. Thanks for enlightening me! BR Thomas _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
