> happen after the issuance which required it to be voided, maybe it was > negotiable instrument, so it goes into the ledger if something were to If I issue a check, say check #126 to John Smith, it is a As for voided transactions, this again comes from the issuance > the documentation, which caused me confusion. > So, when I asked about reverse transactions, I had misread something in >a transaction appended it can be reversed by another transaction I don't know what you mean by voided in this context. >recorded as the direct transaction but with the amounts with the >I don't think I understand the question. 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. 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. 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. 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. 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. 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. This allows people to use their preferred format, avoid ambiguity, and improve the user experience. If no option directive is included, it will default to ISO8601. An option directive could be created that lets users chose their preference of date format. However, I still think this is an area that can and *should* be improved. With this information, I do agree that ISO8601 is the best choice to default to. 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. 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. I clearly walked into this landmine, not realizing it would be such a contentious issue. 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. 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. This feature is helpful because there is never a missing check number that is unaccounted for. 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. As for voided transactions, this again comes from the issuance of checks.

So, when I asked about reverse transactions, I had misread something in the documentation, which caused me confusion. Ledger-cli and hledger support different date formats. Supportingīoth, however, is not possible as this would be ambiguous. One (actually, I see reasons to prefer the European one). Supporting the US locale date format should be preferred to the European PleaseĪlso note that the most common date format in Europe is DD/MM/YYYY (withĭiffernet separators depending on the specific locale). The choice of the date format is deliberate. > between the ISO8601 and the US method, as the four-digit year is either > modified to accept both types as I do not believe there is any ambiguity > record, the US typically uses MM/DD/YYYY dates, and it's almost unheard My most minor gripe, though, it is pretty jarring being in the US, is

Gnucash vs