Moving from GnuCash
872 views
Skip to first unread message
Brandon Anderson
Jun 8, 2021, 4:41:43 PM6/8/21
to Beancount
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.
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.
Daniele Nicolodi
Jun 8, 2021, 6:10:56 PM6/8/21
to bean...@googlegroups.com
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
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.
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.
> 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?
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,
> 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?
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?
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?
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?
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
Martin Blais
Jun 8, 2021, 7:46:02 PM6/8/21
to Beancount
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.
Cheers,
--
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 beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/d5b6ce60-e81c-4434-a16d-1714500a61c8n%40googlegroups.com.
Aakash Mehendale
Jun 9, 2021, 5:51:48 AM6/9/21
to Beancount
On Tuesday, June 8, 2021 at 11:10:56 PM UTC+1 dan...@grinta.net wrote:
Hello Brandon,
On 08/06/2021 22:41, Brandon Anderson wrote:
> 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.
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
> 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 :) :)
-
Daniele Nicolodi
Jun 9, 2021, 8:17:54 AM6/9/21
to bean...@googlegroups.com
On 09/06/2021 11:51, Aakash Mehendale wrote:
>
>
> On Tuesday, June 8, 2021 at 11:10:56 PM UTC+1 dan...@grinta.net wrote:
>
> Hello Brandon,
>
> On 08/06/2021 22:41, Brandon Anderson wrote:
> > 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.
>
> It's *extremely* common *in the US*, where I'm going to surmise Brandon
> is from.
The banking system is broken everywhere, in the US just a bit more :-)
>
>
> On Tuesday, June 8, 2021 at 11:10:56 PM UTC+1 dan...@grinta.net wrote:
>
> Hello Brandon,
>
> On 08/06/2021 22:41, Brandon Anderson wrote:
> > 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.
>
> It's *extremely* common *in the US*, where I'm going to surmise Brandon
> is from.
I guess that is the reason why apps like Venmo are so popular in the US
but not that much in Europe where all bank accounts nowadays have free
online money transfers and charge fees for printing check books. It is
very rare nowadays to find a retail shop that accepts checks in Europe.
Indeed, about half of the checks I wrote where while living in the US,
but this is still only about only one check per year on average.
Cheers,
Dan
Justus Pendleton
Jun 9, 2021, 9:59:56 PM6/9/21
to Beancount
On Wednesday, June 9, 2021 at 4:51:48 PM UTC+7 aakashm...@gmail.com 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.
Thomas den Hollander
Jun 10, 2021, 5:37:17 AM6/10/21
to Beancount
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 just...@gmail.com:
Ben Blount
Jun 10, 2021, 11:20:59 AM6/10/21
to Beancount
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.
--
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 beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/69b0b039-54c0-442a-a6f3-bf0580472483n%40googlegroups.com.
Brandon Anderson
Jun 10, 2021, 1:08:49 PM6/10/21
to Beancount
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.
Brandon Anderson
Ben Blount
Jun 10, 2021, 1:59:31 PM6/10/21
to Beancount
> Voiding checks / reversing transactions
This is similar to returns. I just handle it by zeroing out the expense posting
2021-06-10 * "Buy something"
Expenses:Foo 0 USD ;Was 10 USD. When I return, I set it to 0.
Liabilities:CreditCard -10 USD
Assets:Receivables 10 USD
Assets:Receivables is using Red's great Zerosum plugin. So by adding that plugin I'm expecting the return to show up and it'll show up in that account until it gets matched to a counterposting. You can also mark it like this, which might work better for your check use case.
2021-06-10 * "Buy something"
Expenses:Foo 0 USD ;Was 10 USD. When I return, I set it to 0.
Liabilities:CreditCard -10 USD
Liabilities:CreditCard 10 USD
return_reason: "Missing parts"
> 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
Reconcilation is tedious for sure.
1) Balance assertions can really help, it lets you binary search postings for the error. If your bank for example gives a balance on every transaction, you can add balance assertions in a few strategic spots and see which ones are failing. It'll let you quickly narrow down the range where the error might be (the first spot the balances start failing). Those also are "known good" starting points if you ever have a balance failing in the future.
2) Reviewing transactions to compare against a statement:
If you're like me, I have a ton of transactions in my ledger. It's a lot easier to filter the view down with Fava, bean-query, or with a quick Python loop. As a software developer I imagine you'll appreciate the ease by which you can write scripts that quickly loop over all transactions in your journal. Then you can print them out however you like:
entries, errors, _ = parser.parse_file(filename)
for entry in entries:
if not isinstance(entry, data.Transaction):
continue
# filter or print transactions here
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/fa25c27d-8a81-477b-a963-6f42f9a0ec96n%40googlegroups.com.
Boyd Kelly
Jun 11, 2021, 9:28:20 AM6/11/21
to bean...@googlegroups.com
Hi Brendon,
1) Just say NO to checks!
2) Use ISO dates *everywhere*. Put it as the display format for all your PC's handheld devices etc. You will not regret it later.
3) Start on 2021-06-10!
--
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 beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/d5b6ce60-e81c-4434-a16d-1714500a61c8n%40googlegroups.com.
Daniele Nicolodi
Jun 11, 2021, 3:18:45 PM6/11/21
to bean...@googlegroups.com
On 10/06/2021 19:08, Brandon Anderson wrote:
> 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.
There is no reason to avoid mentioning it. I was just pointing out that
> 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.
if you explain what you would like to do in term of what GnuCash does, a
good fraction of the people on this mailing list do not know what you
are talking about.
>>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.
what was the rationale to remove it but the general idea is that is is
very difficult to design a system that is generally useful without
having a bazilion of configuration knobs. Thus the goal is to provide
building blocks that can be used to easily piece together a reporting tool.
>>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.
regardless of the amount transferred. Actually, the likelihood that
someone that you don't regularly do busyness with accepts a check is
inversely proportional to the amount transferred.
That is one good example of the reasons that made me to say that the
banking system in the US is more broken that in most other places.
>>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.
and cleared transactions is only conventional, Beancount does not assign
any special meaning to them. For this reason, a flag seems the wrong way
to achieve what you want.
If you want to keep track of check in this way, you need to record two
transactions for every check you write: one from a Payable account to an
Expenses account when you write the check and one from an Assets account
to the Payable account when the check is cashed (this is also the only
way to record correctly the dates on which the check is written and on
which it is cashed). If the check is voided, the second transaction
never occurs and you will have instead a transaction reverting the first.
Other accounting suites may offer a different interface to record these
transactions, but this is how things are actually recorded under the
hood. If you deal a lot with checks, a plugin that synthesizes the right
transactions from a more concise representation could be useful. So far
no one seem to have had the need to write such plugin.
> 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.
early ERP systems based on relational databases, where assigning IDs to
things is natural, but representing financial transactions in relational
tables not so much.
I think that you may a bit disoriented using Beancount because it is a
tool that offers building blocks that allows you to implement a workflow
more that a tool that offers an opinionated interface that pushes you
toward a specific way of doing things (making doing things in a way
different than the one imagined by the authors very difficult).
Other than matadata fields, you can also use links to represent
transactions IDs.
> I clearly walked into this landmine, not realizing it would be such a
> contentious issue.
that the current accepted date format is the best choice :-)
> 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.
impression that the option to change the account root names is not the
source of endless bug reports only because almost no one uses it).
Should the option that selects the date format be accepted only before
any date is seen by the parser or should it be allowed to change the
date format through the ledger? What about the option appearing in
included files? Should the option also change the date format used for
reporting? If multiple date formats are allowed in the same ledger,
which one is used for reporting? Which date format should the other
interfaces use for user input?
I don't think the cognitive burden of translating from MM/DD/YYYY dates
to YYYY-MM-DD dates justifies opening this can of worms. It also
remembers me the rental car agency in Boulder where they have a 12 hours
AM/PM hour format to 24 hour format conversion table on the wall behind
the front desk :-)
Cheers,
Dan
Martin Blais
Jun 11, 2021, 4:15:23 PM6/11/21
to Beancount
On Fri, Jun 11, 2021 at 3:18 PM Daniele Nicolodi <dan...@grinta.net> wrote:
On 10/06/2021 19:08, Brandon Anderson wrote:
>>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.
Yup. bean-bake is gone too. I never used bean-bake and I don't recall
what was the rationale to remove it but the general idea is that is is
very difficult to design a system that is generally useful without
having a bazilion of configuration knobs. Thus the goal is to provide
building blocks that can be used to easily piece together a reporting tool.
bean-bake was there to share a frozen / browsable archive of your books.
It was basically scraping bean-web, and when bean-web was removed (in favor of Fava), it had to be removed too for that reason.
redst...@gmail.com
Jun 15, 2021, 3:02:56 AM6/15/21
to Beancount
On Thursday, June 10, 2021 at 10:59:31 AM UTC-7 b...@bben.us wrote:
> 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 processReconcilation is tedious for sure.1) Balance assertions can really help, it lets you binary search postings for the error. If your bank for example gives a balance on every transaction, you can add balance assertions in a few strategic spots and see which ones are failing. It'll let you quickly narrow down the range where the error might be (the first spot the balances start failing). Those also are "known good" starting points if you ever have a balance failing in the future.
+1. I'd go so far as to say if you're spending any significant amount of time reconciling in beancount, your process can likely be improved. Importing data often along with balance assertions is key. Related: writeup I recently did of automated balance assertions while importing data:
Martin Michlmayr
Jun 17, 2021, 5:00:56 AM6/17/21
to bean...@googlegroups.com
* Brandon Anderson <brando...@gmail.com> [2021-06-10 10:08]:
(donations) and sometimes send checks. We use meta-data to track a
number of things (check number, check memo, date we received the
check, date it was deposited, etc).
Checks need special handling because your books need to reflect the
income/expenses when the check was received/sent rather than when it
was deposited. A bank reconciliation has to be done to show how to
get from the figures in your books to the figures in the bank
statement.
I have written a script which creates the bank reconciliation based on
the meta-data.
It's definitely possible to record checks in beancount, but you may
have to create some business logic (such as a bank reconciliation
script) that might already be built-in with GnuCash or other
accounting packages. (I should probably clean up my script and
publish it...)
--
Martin Michlmayr
https://www.cyrius.com/
> I run a small business, so I must keep detailed records and find myself
> writing well over a hundred checks each year.
Software in the Public Interest uses beancount and we receive checks
> writing well over a hundred checks each year.
(donations) and sometimes send checks. We use meta-data to track a
number of things (check number, check memo, date we received the
check, date it was deposited, etc).
Checks need special handling because your books need to reflect the
income/expenses when the check was received/sent rather than when it
was deposited. A bank reconciliation has to be done to show how to
get from the figures in your books to the figures in the bank
statement.
I have written a script which creates the bank reconciliation based on
the meta-data.
It's definitely possible to record checks in beancount, but you may
have to create some business logic (such as a bank reconciliation
script) that might already be built-in with GnuCash or other
accounting packages. (I should probably clean up my script and
publish it...)
--
Martin Michlmayr
https://www.cyrius.com/
Reply all
Reply to author
Forward
0 new messages