Sun, 19 Oct 2014 15:23:10
<CAK21+hMYzN3BXaCJPV++RxZCm=h7fuxsnxwgqjujpkld7z-...@mail.gmail.com>
Martin Blais <[email protected]> wrote...
Wm:
I'm not sure I'm getting this. Surely most of the objects (point in time,
something, amount of that something, who had it before and who had it
afterwards) are easily defined and represented with a bit of glue saying
that-one-over-there and this-one-here belong together, let's call it a
transaction ?
This is a simple and common database-related problem.
You have at least two tables:
One table contains information attached to the transaction.
The other table contains information attached to the posting.
Let's illustrate: let us simplify things grossly and say that transactions
have only
(entry-id, date, flag, payee)
fields and that postings have only
(posting-id, entry-id, account, amount, currency)
fields.
You can join the two tables on some id (easily doable) to obtain a table of
postings plus their corresponding entry data.
If so, you get rows of
(entry-id, date, flag, payee, posting-id, account, amount, currency)
...
The rub here is that you have duplication of the entry information. For
example, given the following transaction:
2014-09-12 * "WALMART"
Assets:Checking -45.00 USD
Expenses:Toys 45.00 USD
You would obtain
(1000, 2014-09-12, "*", "WALMART", 20000, "Assets:Checking", -45.00,
"USD")
(1000, 2014-09-12, "*", "WALMART", 20001, "Expenses:Toys", 45.00, "USD")
Only if you throw in unnecessary stuff, a query need not include junk
Do you not see that the entry fields are duplicated?
Nope, they aren't duplicated
Ok, so you might think, this is not much of a problem.
It is worse than that, I see no duplication at all. I see legs / splits
/ whatever you want to call them of a transaction.
Well, you _can_ generate many meaningful reports this way, but not all
(read on). This is conceptually how Ledger works AFAIK: the filter applies
against the list of postings, as they appear in the file (Ledgerfolk:
please correct me if I'm wrong, this is how I understand it to be).
STOP: you are arguing beancount think vs ledger-cli think
I am not part of that argument!
Deduplication
The problem I referred to as deduplication is that of combining rows of the
same transaction. This is how you would normally want to render a journal's
entries. For example:
2014-09-12 * "WALMART"
Assets:Checking -45.00 USD
Expenses:Toys 15.00 USD
Expenses:Toys 30.00 USD
This should ideally render as a single entry in a journal for
Expenses:Toys. Beancount's journal rendering routines do this
automatically. A GROUP BY for all entry columns for a result set on a list
of postings would be awkward.
Puzzled: why do you think SQL would struggle with this?
I admire your thinking in the sense that you seem to ignore input from
the real world but don't understand why you can't see that a query can
produce a result. Is it possible you are unfamiliar with SQL? <-- a yes
or no will do
Operations on Inventories
A more difficult problem is that the Ledgerverse systems admit any number
and type of units to be stored and accumulated in association with an
account. Accounts don't have associated currencies. This means that summing
the changes defined by postings is not a simple arithmetic operation.
yup, you can have sums of something if you want, all you have to do is
say there is a something associated with a number
Inventory objects are more like "mappings" that contains associations of
(currency, cost, acquisition-date) to a number of units. Adding a new
position has one of two effects: it either creates a new lot, or if there
is already a lot for that (currency, cost, acquisition-date), it adds units
to that lot. Reducing a position is handled differently by Ledger and
Beancount:
... and don't we know it! Do you think I'd be here if I didn't already
know about the differences? FFS, man!
in Ledger, the operation works the same as with the addition of
new lots, except with a negative number. It allows positive and negative
lots in the same inventory. This naturally supports other methods of
booking (you can average all the cost bases, for example) but has the
unfortunate effect of admitting impossible situations, such as an inventory
with a negative cost basis.
Not impossible if you have bought stuff that is yet to be delivered.
Ordinary business.
Reducing a position in Beancount is more
strict:
we know that, I am asking why are you going to all this trouble? I
think it is something personal because it doesn't reflect ordinary
commerce
it requires that an existing lot exist to be removed from.
nope
Therefore, it never allows for both positive and negative numbers for the
same lot. This creates some complications of its own, in particular when
attempting to book positions at average cost (the lots of an inventory need
to be reaggregated) but has the advantage of preventing impossible
situations and resulting only in correct inventories. Both methods have
benefits and difficulties.
I think you are much to concerned with exactness. There is a name for
this but I like you enough not to say it.
Such operations on inventories are difficult to model in SQL. I don't think
it can be modeled easily. I think it's preferable to just provide a query
engine that natively supports such an inventory object upon which positions
can be aggregated.
OK, surely the limitation here is your imagination rather than any
practical db implementation?
My new syntax
I've heard that once to many times and is the reason I won't encourage
people to maintain anything --> beancount. in simple terms you can't
make up your mind what you want
will allow the user to join on the resulting inventory
positions to flatten them out to detailed lists of holdings (these are
useful to compute attributes of portfolios). For example, if the balance of
an account (or a group of accounts) is 20 GOOG, 25 AAPL and 30 MSFT, by
default a result would output a single row like this:
.... 20 GOOG, 25 AAPL, 30 MSFT
it shouldn't, actually
So the user should be able to provide a special option ("FLATTEN") like
this:
SELECT ... FROM ... WHERE ... FLATTEN;
to produce one result row for each lot, like this:
.... 20 GOOG
.... 25 AAPL
.... 30 MSFT
which SQL would do naturally
What are you trying to do?
I stopped reading, sorry
I'll try and find the time tomorrow to read the rest but to be honest I
don't see your point. I raise the issue of, "if no-one is getting my
point should I still be making it after a point in time ?"
Unless I have missed something (and I have tried reading what you have
said) you aren't solving any real world accounting problems.
--
Wm...
--
---
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
