Hey, so I have been using GnuCash for years, and as a software developer, I
like the idea of moving to text-based accounting, which can be
version-controlled and shared between my computers. First, I want to tell
you what a fantastic project you have built; it looks like a ton of work
has been put into it, and I am glad you shared it with the world. As I
explored Beancount, though, I realized there were a few differences between
how records could be kept in Gnucash and some features that GnuCash offered
that I don't believe Beancount currently does. Taking an elementary example
of a checking account transaction, I wish to highlight those to ask if my
implementation in Beancount is the closest representation to the GnuCash
record.
[image: GnuCashExample.png]
Above is the GnuCash record of a transaction to purchase a good with two
elements that it is expensed as. I made the equivalent record as a
Beancount file below.
```
2021-06-08 open Equity:Opening-Balances
2021-06-08 open Assets:Checking-Account
2021-06-08 open Expenses:Groceries
2021-06-08 open Expenses:Bribes
2021-06-08 * "John Smith" "Opening Balance"
Assets:Checking-Account 5,000.00 USD
Equity:Opening-Balances
2021-06-08 * "Willy Wonka" "Everlasting Gobstopper"
check: "226"
Expenses:Groceries 32.76 USD
note: "Gobstopper"
Expenses:Bribes 500.00 USD
note: "Bribe to get Gobstopper Access"
Assets:Checking-Account
```
GnuCash lets you record a note not only for the overall transaction but
also for the individual elements. I did not see such an option in
Beancount, so I assumed the proper way to record that data is with the
metadata field. Though it does not show those notes when looking at the
journal through the bean-web interface, it is visible with the fava
interface. Is this the best way to track notes on individual lines?
Second, it is very common in checking accounts to write checks, and as
checks are numbered, there is typically a field to record the check number
in the ledger. I did not see a proper way to record a check number, so I
used a meta field again, but I feel a transaction declaration should have
an optional number field. Would adding an optional transaction/check number
field be a reasonable feature request?
I am also curious about uncommon situations when recording transactions in
a checking account. What is the proper way to record a reverse transaction
that occurs at a later date? What is the proper way to record a voided
transaction?
One of the features I heavily use on GnuCash, and the only reason I have
not switched over yet is the ability to print checks from recorded
transactions in my ledger. I don't see any ability to print checks, but I
know Beancount has a report generator (though I don't believe it supports
PDF or PostScript). Still, I wonder if it would be possible to add support
for check printing using the report generator as a basis?
My most minor gripe, though, it is pretty jarring being in the US, is the
requirement to use ISO8601 dates. As you can see from the GnuCash record,
the US typically uses MM/DD/YYYY dates, and it's almost unheard of to use
the ISO8601 style. I believe the lexer could trivially be modified to
accept both types as I do not believe there is any ambiguity between the
ISO8601 and the US method, as the four-digit year is either the start or
end of the string. Would adding support for the US-style dates be a
reasonable feature request?
If there is a proper way to record the things I listed above and I am not
doing it that way, please let me know. If the changes I asked about would
not be objected to, I would gladly file a more formal feature request with
the planned changes and then make the changes myself for a merge request. I
just don't want to waste my time making changes if the project does not
accept them once I finish.
--
You received this message because you are subscribed to the Google Groups
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beancount/d5b6ce60-e81c-4434-a16d-1714500a61c8n%40googlegroups.com.
