Hello Brandon, On 08/06/2021 22:41, Brandon Anderson wrote: > 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.
Most Beancount users and developers are not familiar with GnuCash, thus it may be better not to explain what you would like to achieve by similitude or contrast to the features offered by GnuCash. > GnuCash lets you record a note not only for the overall transaction but > also for the individual elements. What you call elements are called postings in Beancount. > 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? I think that by lines you mean again postings. If you need to attach information to postings you can do it only with metadata or comments, but comments are not part of the information Beancount parse from the ledger, thus you cannot query them from Beancount tools. The use of bean-web is discouraged. It has already been removed from what will become the next major version of Beancount. If you like a web interface, use fava. > Second, it is very common in checking accounts to write checks, I wrote maybe 10 checks in my life. I don't think it is that common. > 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? If you don't want to put the check number in the transaction narration, a metadata entry is the way to go. Metadata values can have decimal (thus also integer) values. What would be the advantage of having a special field for the check number in the transaction object? It would make the syntax more complex and it would require extra storage space in the parsed representation for a field that is empty 99.9% of the times. > 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? I don't think I understand the question. A reverse transaction is recorded as the direct transaction but with the amounts with the opposite signs. I don't know what you mean by voided in this context. If a transaction appended it can be reversed by another transaction effectively undoing it. > 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? It can definitely be done, I would be surprised if there isn't already some piece of code out there that does it (either for Beancount or for ledger-cli, in the latter case it would not be too difficult to adapt it to Beancount probably). However, I don't think this feature belongs in Beancount itself. It can be developed as a separate project. > 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? I don't think so. The choice of the date format is deliberate. Please also note that the most common date format in Europe is DD/MM/YYYY (with differnet separators depending on the specific locale). I don't see why supporting the US locale date format should be preferred to the European one (actually, I see reasons to prefer the European one). Supporting both, however, is not possible as this would be ambiguous. Sticking to the ISO format is the best option, IMO. ledger-cli and hledger support different date formats. Cheers, Dan -- 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/a90b2afc-5063-800d-45e2-5a3594d1368e%40grinta.net.
