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". > > >> 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. > > 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. > 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 beancount+unsubscr...@googlegroups.com. To post to this group, send email to beancount@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/94e42078-c4f6-4c46-aa4a-84ed78daa59a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
