On Sat, Jan 7, 2017 at 9:38 AM, Christopher Singley <[email protected]> wrote: > > On Friday, 6 January 2017 23:12:51 UTC-6, Martin Blais wrote: > >> >> >>> Summing for cost [or cost*cost/unit] ties out to balance sheet >>> accounts. >>> >> >> What do you mean by "ties out"? >> > > That's accountant-speak for "equality testing". >
On a somewhat related note: I wonder if a new type of directive could be useful, similar to Balance assertions, that would assert that the total of one account matches that of another. I haven't need it myself just yet, but it's a simple and appealing idea. > >> >>> Each of those subaccounts will have a subaccount for cost, which ties >>> out to the journal with the constraint that sum of cost for a given asset >>> has to equal the costs posted to the relevant balance sheet subaccount on >>> the general ledger. >>> >> >> Instead of using a subaccount, each of the position has its cost attached >> to it. This representation allows us to think of aggregating any type of >> position. This then allows us to formulate queries using something simple >> like SQL. "Sum up all the contents - whatever it is - under those accounts" >> is a working idea. >> > > That's fine too; cost is not really a first-class concept on the financial > statements; it comes in from special journals. > One thing to be aware of is that the goal of this project is not to replicate nor implement traditional methods of accounting. Rather, the purpose is to come up with the simplest possible representation that allows one to enter and effectively query data from text files in the context of personal finance. Given this, I feel quite free to deviate from well-established norms, especially when their existence derives from historical limitations. For example, Beancount adopts Ledger's idea of doing away with credits and debits (preferring signed amounts) and there's no "reconciliation" process, instead you declare balance assertions explicitly. Furthermore, I think there may be simpler ways to solve some accounting problems by taking a CS outlook on them. Inventory's representation is equivalent, but also allows a well-defined >> aggregation of any position. >> I see no disadvantage in the way Inventory represents it compared to a >> hierarchical representation. >> > > I'm not concerned about the structure, I'm simply concerned with speed > when the list gets long. Already I've got problems in that regard... the > OFX parser I put up on github uses regular expressions (so it can handle > OFXv1 too), and it is dog slow when I churn a year's worth of data through > it. For OFXv2 data, using an expat-based parser (dumping much of the > processing from Python to C) speeds things up considerably. > Beancount uses a mostly C parser. No real performance optimizations have been done yet, so there's lot of low-hanging fruit. We'll worry about it when it gets too slow. BTW encapsulation in this case would be a bad thing... the inventory >> matching logic is much better left factored out of the container. Baking >> and "encapsulating" the logic in a method "abstraction" is something I'd >> have done in the 90's when I was much less enlightened and in love with OO >> and Design Patterns (I'm almost ashamed to admit, there was once a >> time...). A better way to build this is to keep the containers dumb and the >> algorithms outside, it's a much more flexible and elegant design. It's on >> purpose. >> > > I meant no criticism - I am here to learn, not to teach. > > But let me scrutinize your booking code, and I'll be able to expose my > ignorance in greater detail, on my own personal road to enlightenment. > > Cheers > Chris > > -- > 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 post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beancount/94e42078-c4f6-4c46-aa4a-84ed78daa59a%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/94e42078-c4f6-4c46-aa4a-84ed78daa59a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPN0Ca9AV5h1yb_Yk0iz0b00nSpfix%2ByKb4bHY%2BySBvJA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
