Thanks Martin, Point taken. Most of my transactions are with external entities therefore payee usually is the proper term. Then there are transactions between accounts of my own, these mostly have a descriptive short name like "Mortgage reservation", "Opening balance", "Country1 2 country2", etc. But also in that case there is a payee which happens to be myself.
So this always is a "transaction name or type" which most often happens to be a payee name. But the syntax does not distinguish these in any way. >From the ledger manual: 5.1 Basic format The most basic form of transaction is: 2012-03-10 KFC Expenses:Food $20.00 Assets:Cash $-20.00 This transaction has a date, a payee or description, a target account (the first posting), and a source account (the second posting). Then in the chapter 4.7 Journal Format: 4.7.1 Transactions and Comments The initial character of each line determines what the line means, and how it should be interpreted. Allowable initial characters are: NUMBER A line beginning with a number denotes a transaction. It may be followed by any number of lines, each beginning with white-space, to denote the transaction’s account postings. The format of the first line is: DATE[=EDATE] [*|!] [(CODE)] DESC If ‘*’ appears after the date (with optional effective date), it indicates the transaction is “cleared”, which can mean whatever the user wants it to mean. If ‘!’ appears after the date, it indicates the transaction is “pending”; i.e., tentatively cleared from the user’s point of view, but not yet actually cleared. If a CODE appears in parentheses, it may be used to indicate a check number, or the type of the posting. Following these is the payee, or a description of the posting. So assuming the manual is correct, the distinction is not made in ledger. There is always a description, which sometimes happens to represent the payee but it doesn't have to. Op zaterdag 12 juli 2014 17:54:26 UTC+2 schreef Martin Blais: > > No, you don't always have a payee. > You typically only have a payee where you have an expense account, and not > always. > > Why? > Let's first look at a transaction between your own accounts, say between > your checking account and an investment account: > > 2014-06-27 * > Assets:MyBank:Checking -1000 USD > Assets:Vanguard:Cash > > Who's the payee? > - The account is held in your name on both sides. > - Both sides have an institution associated with them, which is not the > payee (you are) > - Each account, by its name, fully specifies which that institution is, so > you don't need to put that in, if you thought of this as "the payee." > > ... this transaction has no payee! > And if you've got a reasonably detailed chart-of-accounts, this is the > case for almost all accounts of types Assets, Liabiltiies and Income. > > > About Assets and Liabilities accounts: > These accounts have your name on it, so you're the payee. Transactions > that involve only these types of accounts have no payee (by its definition > of "an external entity"). > > > About Income accounts: > Income almost always has recurring transactions - you either work as an > employee and get multiple payments, or you do contract work and your work > does repeat from the same client (to which you send incomes and such), and > you will typically want to create an account for this client's source of > income anyhow. > > There are exceptions: for example, I sell books via PayPal. Every > "customer" is a new and different one and the great majority of them buys > the book only once; it would make no sense to create a subaccount for each. > That's an excellent use case to use a payee on an income account. > > > About Expenses accounts: > Then you have expenses, which we tend to book to accounts associated with > "categories." You might ask, why do we do that? This would be a legitimate > question. For example, why don't we define Expense accounts to whichever > entity we're sending the payments to? Like this: > > Expenses:ConEdison > Expenses:TMobile > Expenses:WholeFoodsMarket > Expenses:UnionMarket > > This is for the same reason as the Income account example I provided > above: many of the expenses transactions one incurs occur only once for > each instutition, so we book them to accounts whose meanings associate > closer to "categories": > > Expenses:Electricity > Expenses:Phone > Expenses:Groceries > > and then we might use "payees" as a way to determine where the money > actually went for a particular category, by reporting aggregations "by > payee". > > In the majority of these cases, all the payments to a single payee will > book into the same category, so you could use subaccounts of the categories > instead of payees: > > Expenses:Electricity:ConEdison > Expenses:Phone:TMobile > Expenses:Groceries:WholeFoodsMarket > Expenses:Groceries:UnionMarket > > This still fully determines which external entity the money is going to, > just by virtue of the account name, and you don't need a separate payee > field. Your ability to report those then depends ONLY on the ability to > aggregate to parent accounts: > > Expenses:Electricity:* > Expenses:Phone:* > Expenses:Groceries:* > > If you can aggregate this way, these methods are entirely equivalent IMO. > I've been thinking about adding a reporting feature to Beancount whereby it > would report payees as sub-accounts (i.e., define subaccounts > automatically), which might be fun and it might make sense. > > If you just use the "category only" method, then almost all the > transactions you book to expenses have a payee (unless it's a summarizing > transaction with multiple expense postings that implies multiple payees, in > which case you're out of luck - you can't identify just one as the payee). > > Now, there are exceptions for Expenses too: if you do business with some > external entity that you end up booking transactions to multiple different > accounts for, especially if you are not able to define these accounts to > share the same parent account (i.e., they might be in different categories, > e.g., Income and Assets), then you might want to use payees to group these > together. Those are much fewer in my experience, and besides your reporting > could work if the related accounts share some common component of their > name, e.g. "Vanguard" in the following list of accounts: > > Assets:Vanguard:Cash > Assets:Vanguard:AAPL > Income:Vanguard:Dividends > Expenses:Fees:Vanguard > > You can then filter the report by selecting all accounts with the name > "Vanguard" in them. No need for a payee. > > So in short: most transactions do not need have a payee. > > > > It also occurs to me that we don't yet have a good definition of what a > "payee" is. I think of it as: "an external entity," that is, to an account > where the funds accumulated aren't mine. I realize that it is possible that > you think of a "payee" as the institution/entity associated with the > account that is receiving the funds (i.e., gets a positive change posted to > it, a credit). > > > > And about comments and narration: comments are not good for this use. They > do not get parsed. Narrations get stored with the transaction entries and > get rendered, they must get parsed. They need to be part of the syntax, not > ignored as comment material. > > I do think that there's space to allow > - A payee only (many cases) > - A narration only (many cases) > - Both a payee and a narration > > With the syntax I've defined, when I need only a payee, I put an empty > narration string. It is slightly less than ideal, but it works, and I don't > come across that many occurrences of this. > > > Finally, there isn't "your world" and "my world", there is "one world." > While it's nice to build a generic system that allows us to do count > anything we want without restrictions (and Beancount also falls in that > category BTW, apart from disallowing virtual transactions, it imposes > little restrictions), it doesn't obliviate the fact that there are > principles that can emerge about tracking financial activities, and > surfacing these principles and analyzing their forces - their individual > strengths and weaknesses - allows us to provide guidelines for choice and > usefulness. I'm very interested in this. I think we should be able to show > that some methods are objectively better than others, and then recommend > these methods. > > If you have a payee for every single transaction, I have a feeling you may > not have explicitly chosen a tight definition of what the "payee" is. Am I > right? If you do have one, please contribute your definition, I'd love to > hear it. > > > > > On Sat, Jul 12, 2014 at 5:08 AM, Hans Erik van Elburg < > hanserik....@gmail.com <javascript:>> wrote: > >> That is a rather ambigous syntax. Especially because in my world there is >> always a payee and "narration" is optional. >> It would be more logical to always use the first position for payee... >> and use a comment line for any "narration" >> >> Op zaterdag 12 juli 2014 06:17:20 UTC+2 schreef Martin Blais: >>> >>> I thought I recalled there being a payee and a narration. >>> Maybe it changed in Ledger and this moved to a "tag". >>> Back in the day, if i recall correctly, the idea was to have optional >>> payee + narration. >>> It is still like that in Beancount: >>> >>> ; with payee >>> 2014-05-20 * "Whitman's" | "Burger with friends" >>> >>> ; with just narration >>> 2014-05-20 * "Dinner w/ family" >>> >>> The "|" is now optional, because the v2 Beancount syntax has a notion of >>> "strings", so it provides a natural delimiter. >>> One string -> narration >>> Two strings -> payee + narration >>> >>> Anyhow. >>> >>> >>> >>> >>> On Fri, Jul 11, 2014 at 9:58 PM, Craig Earls <ende...@gmail.com> wrote: >>> >>>> I call that the 'payee' >>>> >>>> >>>> On Friday, July 11, 2014, Martin Blais <bl...@furius.ca> wrote: >>>> >>>>> It's just the inverse of the arration. >>>>> No, just kidding. >>>>> >>>>> The narration is the descriptive string that comes after the date and >>>>> the flag: >>>>> >>>>> 2014/05/06 * Hi I am the narration >>>>> ... >>>>> ... >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jul 11, 2014 at 6:56 PM, Craig Earls <ender...@gmail.com> >>>>> wrote: >>>>> >>>>>> What is "narration"? >>>>>> >>>>>> >>>>>> On Friday, July 11, 2014, Martin Blais <bl...@furius.ca> wrote: >>>>>> >>>>>>> On Fri, Jul 11, 2014 at 12:18 PM, Jules van >>>>>>> >>>>>>> Can you not use the narration for this? >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Ledger" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to ledger-cli+unsubscr...@googlegroups.com. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Craig, Corona De Tucson, AZ >>>>>> enderw88.wordpress.com >>>>>> >>>>>> -- >>>>>> >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Ledger" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to ledger-cli+unsubscr...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>>> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Ledger" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to ledger-cli+unsubscr...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> -- >>>> Craig, Corona De Tucson, AZ >>>> enderw88.wordpress.com >>>> >>>> -- >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "Ledger" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to ledger-cli+...@googlegroups.com. >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "Ledger" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to ledger-cli+...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
