Oh! Please, don't use a period at the end of a number to mean
anything. Some people and places already get easily confused by
2,000.01. Is that equivalent to two thousand and one hundredth or two
and one hundred-thousandth?
Even if there is no parsing ambiguity for ledger, I think some
On Aug 16, 2010, at 12:58 PM, Łukasz Stelmach wrote:
Then the getquote interface should support specifing the date to get
the exchange rate at the time (day) of the transaction[*], save it in
the pricedb in the correct place, and query the pricedb when building
reports. In general the idea
On 8/1/10 3:23 PM, John Wiegley wrote:
For a long time I've had a feature request for account definitions:
account NAME
kind...
commodity $
strict
Interesting. It would be nice if this could define valid account names as well, when desired, to catch mispelings.
Keeping it
On Aug 2, 2010, at 11:38 AM, Simon Michael wrote:
Interesting. It would be nice if this could define valid account names as
well, when desired, to catch mispelings. Keeping it optional, lightweight and
simple enough. I need this too.
Yes, they could be used for defining the allowable set of
I was thinking about commodity valuations last night, and I realized there is
fundamental detail which Ledger has no concept of right now: the finality of
postings.
There are postings which are open, waiting to be closed on another day.
For example, if I get paid at work, I now have money that is
Postings which move amounts into or from these accounts will
always show amounts in terms of the posting's value at that time.
I'm a bit confused about this part. How would this work for cash
accounts? How is the value at the time calculated? More specifically,
does this mean that it will show
On Jul 30, 2010, at 4:26 AM, Roel Vanhout wrote:
I'm a bit confused about this part. How would this work for cash
accounts? How is the value at the time calculated? More specifically,
does this mean that it will show me the Net Present Value of my
accounts? That would be strange, considering
On Jul 30, 2010, at 4:58 AM, John Wiegley wrote:
The default will be as it now, that all values are open. I simply propose
adding syntax will let you state that some transactions are now historical
fact, and should vary in their reported value on any future report.
I meant:
The default will
So this is only for currency fluctuations? Because the 20$ movie
example made it seem like it was about accounting for time value
fluctuations.
Still, in a 'traditional' accounting system you'd convert the amount
to your 'native' currency, using the fixed exchange rate, at the time
you book the
On Jul 30, 2010, at 5:07 AM, Roel Vanhout wrote:
So this is only for currency fluctuations? Because the 20$ movie
example made it seem like it was about accounting for time value
fluctuations.
Still, in a 'traditional' accounting system you'd convert the amount
to your 'native' currency,
On Fri, Jul 30, 2010 at 11:25 AM, John Wiegley jo...@newartisans.com wrote:
Let's give a quick example that is the actual reason for this idea:
2009-04-17 * Got KRW from the ATM
Assets:Cash 17 KRW
Assets:Current -102.71 EUR
2009-04-18 * Business dinner
On Jul 30, 2010, at 5:41 AM, Roel Vanhout wrote:
But then we come back to the line in your first mail, Reflecting on
this, it seems that Income/Expenses are by nature final categories,
while Assets/Liabilities are open. Which is deeply embedded in the
whole double bookkeeping system already,
On Fri, Jul 30, 2010 at 11:44 AM, John Wiegley jo...@newartisans.com wrote:
Another possibility is adding a -H COMM flag, which is exactly like
-X COMM, except that it converts values using the day of the
transaction, rather than today. This just means you can't have an
all-in-one balance
13 matches
Mail list logo
