Wow, I was not expecting that much feedback; I will try and answer each point that was brought up.
>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. Understood, I figured it was a good comparison as it's an open-source double book accounting software and was what I am familiar with, but I will avoid referencing it in the future. >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. Yes, I was referring to postings. I will try and use that term from now on. >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. Good to know. Does that mean bean-bake is also being deprecated? I liked the idea of being able to build a static web report you could hand to someone. >I wrote maybe 10 checks in my life. I don't think it is that common. I run a small business, so I must keep detailed records and find myself writing well over a hundred checks each year. For small amounts of money, I can see why checks have fallen out of favor. Still, once transactions are into the many thousands, the transaction fees charged by most banks for credit/debit/electronic deposit/withdrawal can become quite excessive. I imagine many running their own small business probably still write checks frequently; maybe I am wrong. >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. As I have tested out Beancount more and more, I realize the metadata field is quite powerful, and if checks are not something most people use, it's probably the better route to go. This was the first time I have ever used, let alone seen, a double book accounting system that does not let one number or reference transactions. >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. So, when I asked about reverse transactions, I had misread something in the documentation, which caused me confusion. So you can ignore that question. As for voided transactions, this again comes from the issuance of checks. If I issue a check, say check #126 to John Smith, it is a negotiable instrument, so it goes into the ledger; if something were to happen after the issuance which required it to be voided, maybe it was never received or was misprinted I need a way to keep the record in the ledger because a check was printed, and simply mark that it has been invalidated. This feature is helpful because there is never a missing check number that is unaccounted for. Ideally, there would be a flag to mark voided transactions as there are '!' for incomplete or uncleared transactions, and '*' for completed transactions, there could be a 'v' or some other symbol to mark voided transactions. After looking over the documentation, I am guessing the best course of action currently would be to log an event directive? I still want to keep the records of the accounts the check was issued to/from, though, so would that go into metadata on the event. >>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. >It's *extremely* common *in the US*, where I'm going to surmise Brandon is from. A commercial US accounting package that didn't know about checks would be laughed out of the room. >But, as Martin has already suggested, there's no need to special handling in beancount; it's just another kind of metadata Indeed, I am from the US, and while it's not a commercial accounting package, ideally, it should be able to handle a very small LLC. As I have experimented more with it, I think the metadata field is probably sufficient. I have not found anything to print checks with, so before I transition to Beancount, I will write a plugin to support printing checks. >There's no such thing as checks where I live, so I'd be a bit put out if beancount made them a fundamental part of the schema just because America has an archaic banking system ;-) Having the option to place an ID or reference to a transaction does not require it to be solely for checks; it could be referencing invoice numbers, etc. But the metadata feature seems powerful enough to make it unnecessary anyway. It was just weird not seeing a number field for transactions. I think it depends upon what you are using the software for. If you just want to track your personal finances, then it might seem silly; if you own a small business, then not so much. >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. >For check numbers and per-postings description use metadata. >ISO8601 dates sort naturally. >Part of the design aesthetic in this project is to keep things simple, e.g. minimal number of options and variants >I'm shocked, *shocked*, to see a software developer asking for MM/DD/YYYY over ISO8601 :) :) >Why should US dates get preferential treatment here? Why not Australian dates? >DD/MM/YYYY is also unambiguous with ISO8601. >There are very few countries that use MM/DD/YYYY: https://en.wikipedia.org/wiki/Date_format_by_country >It's good that there is a date format that is unambiguous, not only for the parser but also for people who don't know which format is used in the first place. >Add an American, +1. ISO format is best. Let's hope someday rationality will prevail and we can dump the base 2 based imperial system too. I clearly walked into this landmine, not realizing it would be such a contentious issue. I admit I had a brain fart and forgot that there is a DD/MM/YYYY format in everyday use in other countries when I wrote that suggestion. Many people have pointed out that it creates an ambiguity in how it would be parsed if you supported both and unfair if you supported just one. With this information, I do agree that ISO8601 is the best choice to default to. However, I still think this is an area that can and *should* be improved. An option directive could be created that lets users chose their preference of date format. If no option directive is included, it will default to ISO8601. This allows people to use their preferred format, avoid ambiguity, and improve the user experience. I am less than enthusiastic about using the ISO8601 date format because it is different from the records on my bank, credit, and debit card statements. When I get a statement and attempt to reconcile my ledger against the bank records, if an error should exist in my records, going through hundreds of transactions trying to find the missing or erroneous record is already a tedious process. Having two different date formats between my ledger and the bank statements when doing this process adds another pain point to the user experience of this already tedious task. While I know Beancount tries to keep things simple and with a minimal number of options, I think the added complexity is worth the improvement to the user experience. If you don't care about any date format other than ISO8601, nothing changes for you, but if you prefer a local date format, having the option is something I think would be a massive improvement. I would add that Beancount already supports by option directive the ability to rename account types to what a user would prefer, so it is not so out there to add a similar option directive to change date types. Sincerely, Brandon Anderson On Thursday, June 10, 2021 at 8:20:59 AM UTC-7 [email protected] wrote: > Add an American, +1. ISO format is best. Let's hope someday rationality > will prevail and we can dump the base 2 based imperial system too. > > On Thu, Jun 10, 2021, 02:37 Thomas den Hollander <[email protected]> > wrote: > >> There are very few countries that use MM/DD/YYYY: >> https://en.wikipedia.org/wiki/Date_format_by_country >> >> It's good that there is a date format that is unambiguous, not only for >> the parser but also for people who don't know which format is used in the >> first place. >> >> Op donderdag 10 juni 2021 om 03:59:56 UTC+2 schreef [email protected]: >> >>> On Wednesday, June 9, 2021 at 4:51:48 PM UTC+7 [email protected] >>> wrote: >>> >>>> It's *extremely* common *in the US*, where I'm going to surmise Brandon >>>> is from. A commercial US accounting package that didn't know about checks >>>> would be laughed out of the room. >>>> >>> >>> Good thing beancount isn't a commercial US accounting package :-) >>> >>> There's no such thing as checks where I live, so I'd be a bit put out if >>> beancount made them a fundamental part of the schema just because America >>> has an archaic banking system ;-) >>> >>> > 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'm shocked, *shocked*, to see a software developer asking for >>>> MM/DD/YYYY over ISO8601 :) :) >>>> >>> >>> Why should US dates get preferential treatment here? Why not Australian >>> dates? >>> >>> DD/MM/YYYY is also unambiguous with ISO8601. >>> >> -- >> > 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/69b0b039-54c0-442a-a6f3-bf0580472483n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beancount/69b0b039-54c0-442a-a6f3-bf0580472483n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/fa25c27d-8a81-477b-a963-6f42f9a0ec96n%40googlegroups.com.
