simonmichael/20171012

## 20171012
[Thu Oct 12 2017]
<immae> Hey all! I'm facing a tricky situation with ledger: https://paste.ee/p/BNWVU Any hint?
                                                                [02:03]
<sm> immae: nice example                                        [05:48]
<immae> :D
<immae> I figured out I could sort of solve the point (2) by selling "2.0 Foo {100.00 EUR} @ 250.00 EUR" and "4.0 Foo {150.00 EUR} @ 250.00 EUR", which is equivalent, but much longer to compute if I have like 10 values
                                                                [05:53]
<immae> And ideally, I wouldn't need to compute the 2.0 and 4.0 myself, but it looks like ledger doesn't like "6*5/(10+5) Foo {100.00 EUR}" or any combination I could think of
                                                                [05:55]
<immae> (and same problem of very long computation if I have more shares)
                                                                [05:57]
<sm> I wonder if the tool should let you say {longest-held} or {average} and do the necessary
                                                                [07:14]
<sm> unrelated: I wonder if it ever makes sense to specify {100 EUR} at purchase time, it seems to overlap with P as a way to specify prevailing price
                                                                [07:16]
<sm> when would {PRICE} ever differ from the P MARKETPRICE ?
<sm> in a purchase, I mean                                      [07:17]
<immae> When the price is precise to the tenth of cent, but due to rounding you have some difference
                                                                [07:34]
<immae> Or the inverse, you buy 3.14159 Foo for 235 EUR in total: the marketprice will not be "round" even though the actual price may be precise
                                                                [07:35]
<sm> immae: hmm, ok.. so it can be used for fine-tuning the precision
                                                                [07:39]
<immae> yes                                                     [07:40]
<immae> A first step would be to allow expressions like "6*5/(10+5) Foo {100.00 EUR}" (rather than imposing specific longest-held and average terms)
                                                                [07:43]
<immae> As far as I see, it's not possible to have {...} in expressions
<immae> (buy maybe I don't write it correctly)
<immae> Trying to read the expression parser to understand how it works, I'm a bit lost :p
                                                                [07:44]
<sm> it seems {PRICE} has a different meaning depending on the sign of the amount
                                                                [07:47]
<immae> hmm not as far as I remember?                           [07:48]
<immae> (I read that part of the code that parses posting, I only skipped the expression part because it was too complicated)
<immae> but maybe I missed something
<sm> when you're buying, {PRICE} means "override the prevailing market price with this". When selling, it means "sell a lot consisting of items purchased at this market price"
                                                                [07:50]
<immae> right                                                   [07:51]
<immae> but in practice it's the same                           [07:52]
<immae> If you add --lot-prices, they are handled the same way
* sm 's brain explodes
<immae> As said in the documentation, it helps to consider "Foo {PRICE}" as a single commodity
                                                                [07:54]
<immae> Different from "Foo {PRICE2}"
<sm> yes
<sm> --lot-prices is a display flag, showing that detail, I see
<immae> yes                                                     [07:55]
<sm> ...and also affecting how ledger balances those amounts, I think
<immae> When you buy Bar's using EUR whithout specifying the {PRICE}, it is computed automatically
                                                                [07:56]
<immae> starting there, every bought commodity is actually a Commodity {Price}
<immae> (from ledger's view)
<sm> yes                                                        [07:57]
<immae> (a bought commodity is a commodity that appear in the first posting of a multi-commodity transaction)
<immae> So far, ledger is perfect. The problem comes afterwards when you sell a commodity without specifying a {price}
                                                                [07:58]
<sm> woah.. are you saying the order of postings changes the meaning ?
                                                                [07:59]
<immae> as long as you don't say --lot-prices, you can believe it's all right
<immae> sm: yep
<sm> that's in the manual somewhere, I guess. I wasn't aware    [08:00]
<immae> Search for "When an xact involves two different commodities" in the source code
<immae> Or yes, I'm sure it's somewhere in the manual
<immae> http://ledger-cli.org/3.0/doc/ledger3.html#Primary-commodities
                                                                [08:01]
<sm> ah, thanks! I did know about that
<sm> well. I knew something about it. I didn't know it meant the words you just said :)
                                                                [08:02]
<sm> another question/observation: I think {PRICE} is meaningful only in a purchase or sale. It wouldn't make sense in a transaction transferring between two asset accounts
                                                                [08:03]
<immae> I actually spent a lot of time reading the posting/transaction parser to understand all the subtelties
<immae> sm: Depends how you see things                          [08:04]
<sm> immae++ code-reading
<immae> If you don't move *all* your assets, you may say: I move the Foo that I bought at 5EUR, but not the ones that I bought at 20EUR
<sm> ah
<sm> so, using it as a lot selector, again                      [08:05]
<immae> yes
<immae> And from ledger you'll end up with two commodities in your "from" account: a -6Foo (you just transfered) and a 50 Foo {PRICE}
<immae> (I need to check that)
<immae> https://paste.ee/p/VizxG                                [08:07]
<immae> yep
<immae> In this example, at the end your Broker2 has 10.00 Foo, and you Broker1 has -10.0 Foo + 10.0 Foo {150.00 EUR} + 5.0 Foo {100.00 EUR}
                                                                [08:08]
<immae> https://paste.ee/p/oTU6r sorry (typo)                   [08:09]
<immae> so three distinct commodities                           [08:10]
<sm> yes..                                                      [08:12]
<immae> This is expected and normal
<immae> (from my point of view at least)
<sm> so if you use --lot-prices, you had better always provide a lot selector when withdrawing priced amounts
                                                                [08:13]
<immae> yes                                                     [08:14]
<immae> And to get away from tax penalties you'd better use them too
                                                                [08:15]
<immae> (and know how your country consider commodity sales)
<sm> indeed, it was informative how you contrasted the US and France policy (longest held vs average)
                                                                [08:16]
<sm> For now I find it confusing that specifying the market price applicable in a purchase and selecting the lot for a sale/transfer use the same syntax
<sm> perhaps in a while I'll see that it makes sense            [08:17]
<sm> thanks for your helpful explanations
<immae> You're welcome :)
<immae> (Still stuck with my own question though :D )           [08:18]
<sm> yes. sorry. :)
<immae> If you can read c++, it's definitly a good idea to read the transaction parser
<immae> This is how I learnt and understood all that            [08:19]
<sm> it seems like there should be a kind of lot transfer/sale that fails if the specified lot does not exist in the asset account
                                                                [08:22]
<immae> no, it will be simply negative ;)                       [08:23]
<sm> I know, but.. perhaps I'm talking about a layer above ledger's free-wheeling mathematical operations
<immae> Yes                                                     [08:24]
<sm> because if you're just doing finance, it seems too easy to create balances with arbitrary/non-existent lots
<sm> but without --lot-prices, maybe it all looks fine. I dunno
<sm> This stuff is complicated                                  [08:25]
<immae> This is why you should have things like the US example in https://paste.ee/p/BNWVU (a "capital gain" for the difference between the selling and buying)
<immae> without --lot-prices it looks fine
<immae> the tax taker will be the only one pissed by that :p
<sm> I'm sure                                                   [08:27]
<immae> (and if you look closely at your total balance without --lot-prices you'll see that it doesn't balance to 0)
                                                                [08:28]
<sm> I expect I'll get the hang of this stuff when I have more need of it
<immae> If you want to use bitcoins as a commodity (to buy stuff), You'll need to
                                                                [08:29]
<immae> At least in France
<sm> noted
<sm> while if you're just acquiring and saving them, probably not
                                                                [08:30]
<immae> As long as you don't sell them, you're fine
<immae> (note that rules are country-dependent, and the differences are not negligible)
                                                                [08:31]
* sm nods
* sm must get back to thinking about budgeting                  [08:35]
<immae> sm: Just had an idea (valid for French accounting, then): as soon as you buy a commodity at two different prices, France taxing considers that you have only one commodity at the average price. Then, we can just make ledger take it that way: https://paste.ee/p/SYmNo
                                                                [08:37]
<immae> As soon as I buy a new Foo, I update all the prices to an average one
<immae> I still don't like this 133.33333 but we're almost there
                                                                [08:38]
<sm> nice. Modelling the reality.
<immae> (I wish I could squeeze the two adjustments into one transaction...)
                                                                [08:45]
<sm> huh.. can't you ?                                          [08:53]
<immae> Yes you can: https://paste.ee/p/wdSuf                   [08:54]
<immae> And you can merge the adjustment in the above transaction
                                                                [08:56]
<immae> which makes it "one operation"

## 20171015
<immae> As far as I see, {...} is not supported in hledger      [09:10]
<sm> correct, or at most it's ignored                           [09:11]
<sm> I've been trying to understand this stuff well enough to add it for long time
<sm> I'm getting some new clarity I think                       [09:12]
<immae> This one doesn’t compile: https://paste.ee/p/aIrAY
...
<sm> I see: current hledger supports {=PRICE} (and ignores it), and rejects {PRICE}
                                                                [09:14]
<immae> Is it because you didn’t understand it before and thus didn’t include it, or another reason?
                                                                [09:15]
<sm> probably I didn't understand it, or it changed, and mainly lack of time/urgency
                                                                [09:16]
<immae> ok
<sm> I'm keen on understanding/clarifying/improving the pricing syntax somehow
<sm> maybe something could be done in ledger too                [09:17]
<immae> Now that I understood how it works, I’m quite happy by the syntax, so I think I cannot help you there
<sm> cool
<sm> I'm not 100% convinced I need to implement the separate {} syntax
<immae> What do you mean?                                       [09:18]
<immae> With respect to @ ?
<immae> (But I’d dream of having things like 100.0 Foo {(100 EUR / 2)}, It’s just out of my C++ skills...)
<sm> yes. I feel like I could get the reports people care about, with @ plus some way of specifying the "lot retention" (?) strategy
                                                                [09:19]
<immae> It seems quite important to me to track a commodity price somewhere
                                                                [09:21]
<immae> Be it only for historical purposes
<immae> ledger handles it with {..}
<sm> I think the price that's important to remember is the purchase price. That's specified with @ and that informatino must stay with the amount (making a lot). NO ?
                                                                [09:22]
* sm did not mean to shout :)
<immae> It could, sure, but then you’d have different meaning of @ depending on if you sell or buy
<immae> Homogeneity seems important too                         [09:23]
<sm> when selling, the selling price is specified with @. As usual, and symmetric with the above. No problem ?
<immae> then how do you specify that you sold a lot of another price
                                                                [09:24]
<immae> You buy 2 Foo's at 10.00 EUR each, then 5 Foo's at 40.00 EUR each
<sm> when we sell, we must specify exactly which lots were sold, that's clear
<immae> Yes, but then you cannot specify at which price you sold them
<immae> you need both {...} and @ to specify the lot price and the price at which you sell the lot
                                                                [09:25]
<sm> how should we specify the lots ? I think trying to do it by price is confusing and too limited
<immae> with ledger you can specify a lot price {..} and/or a lot date [2000/10/12]
<sm> we could instead have a higher level approach, eg specify the strategy required by your tax authority, and let the tool work out the details
                                                                [09:26]
<sm> which I think is what people actually need
<immae> How about having different strategies in a single file?
<sm> that could be supported
<sm> I don't know if the strategy should be per user, per file, per commodity, per transaction..
                                                                [09:27]
<immae> per account?
<sm> or that
<immae> it could be per transaction with a default that could be defined outside
                                                                [09:28]
<immae> per posting*
<sm> certainly. Ideally, just enough flexibility/complexity to meet real-world needs
                                                                [09:30]
<sm> how many strategies are there, I wonder ? I've heard of LIFO (US) and average (FR)
                                                                [09:31]
<immae> no idea
<sm> no matter                                                  [09:32]
* sm . o O ( a "lot" is an amount + a purchase price + a purchase date )
                                                                [09:37]
<immae> Yep                                                     [09:38]
<immae> (you could still buy two lots at the same date and same price and not be able to distinguish :p )
<immae> (if you have two broker accounts, that could make a difference in taxation :p )
                                                                [09:39]
<immae> (but I guess it’s not that important)
	[Thu Oct 12 2017]
	<immae> Hey all! I'm facing a tricky situation with ledger: https://paste.ee/p/BNWVU Any hint?
	[02:03]
	<sm> immae: nice example [05:48]
	<immae> :D
	<immae> I figured out I could sort of solve the point (2) by selling "2.0 Foo {100.00 EUR} @ 250.00 EUR" and "4.0 Foo {150.00 EUR} @ 250.00 EUR", which is equivalent, but much longer to compute if I have like 10 values
	[05:53]
	<immae> And ideally, I wouldn't need to compute the 2.0 and 4.0 myself, but it looks like ledger doesn't like "6*5/(10+5) Foo {100.00 EUR}" or any combination I could think of
	[05:55]
	<immae> (and same problem of very long computation if I have more shares)
	[05:57]
	<sm> I wonder if the tool should let you say {longest-held} or {average} and do the necessary
	[07:14]
	<sm> unrelated: I wonder if it ever makes sense to specify {100 EUR} at purchase time, it seems to overlap with P as a way to specify prevailing price
	[07:16]
	<sm> when would {PRICE} ever differ from the P MARKETPRICE ?
	<sm> in a purchase, I mean [07:17]
	<immae> When the price is precise to the tenth of cent, but due to rounding you have some difference
	[07:34]
	<immae> Or the inverse, you buy 3.14159 Foo for 235 EUR in total: the marketprice will not be "round" even though the actual price may be precise
	[07:35]
	<sm> immae: hmm, ok.. so it can be used for fine-tuning the precision
	[07:39]
	<immae> yes [07:40]
	<immae> A first step would be to allow expressions like "6*5/(10+5) Foo {100.00 EUR}" (rather than imposing specific longest-held and average terms)
	[07:43]
	<immae> As far as I see, it's not possible to have {...} in expressions
	<immae> (buy maybe I don't write it correctly)
	<immae> Trying to read the expression parser to understand how it works, I'm a bit lost :p
	[07:44]
	<sm> it seems {PRICE} has a different meaning depending on the sign of the amount
	[07:47]
	<immae> hmm not as far as I remember? [07:48]
	<immae> (I read that part of the code that parses posting, I only skipped the expression part because it was too complicated)
	<immae> but maybe I missed something
	<sm> when you're buying, {PRICE} means "override the prevailing market price with this". When selling, it means "sell a lot consisting of items purchased at this market price"
	[07:50]
	<immae> right [07:51]
	<immae> but in practice it's the same [07:52]
	<immae> If you add --lot-prices, they are handled the same way
	* sm 's brain explodes
	<immae> As said in the documentation, it helps to consider "Foo {PRICE}" as a single commodity
	[07:54]
	<immae> Different from "Foo {PRICE2}"
	<sm> yes
	<sm> --lot-prices is a display flag, showing that detail, I see
	<immae> yes [07:55]
	<sm> ...and also affecting how ledger balances those amounts, I think
	<immae> When you buy Bar's using EUR whithout specifying the {PRICE}, it is computed automatically
	[07:56]
	<immae> starting there, every bought commodity is actually a Commodity {Price}
	<immae> (from ledger's view)
	<sm> yes [07:57]
	<immae> (a bought commodity is a commodity that appear in the first posting of a multi-commodity transaction)
	<immae> So far, ledger is perfect. The problem comes afterwards when you sell a commodity without specifying a {price}
	[07:58]
	<sm> woah.. are you saying the order of postings changes the meaning ?
	[07:59]
	<immae> as long as you don't say --lot-prices, you can believe it's all right
	<immae> sm: yep
	<sm> that's in the manual somewhere, I guess. I wasn't aware [08:00]
	<immae> Search for "When an xact involves two different commodities" in the source code
	<immae> Or yes, I'm sure it's somewhere in the manual
	<immae> http://ledger-cli.org/3.0/doc/ledger3.html#Primary-commodities
	[08:01]
	<sm> ah, thanks! I did know about that
	<sm> well. I knew something about it. I didn't know it meant the words you just said :)
	[08:02]
	<sm> another question/observation: I think {PRICE} is meaningful only in a purchase or sale. It wouldn't make sense in a transaction transferring between two asset accounts
	[08:03]
	<immae> I actually spent a lot of time reading the posting/transaction parser to understand all the subtelties
	<immae> sm: Depends how you see things [08:04]
	<sm> immae++ code-reading
	<immae> If you don't move all your assets, you may say: I move the Foo that I bought at 5EUR, but not the ones that I bought at 20EUR
	<sm> ah
	<sm> so, using it as a lot selector, again [08:05]
	<immae> yes
	<immae> And from ledger you'll end up with two commodities in your "from" account: a -6Foo (you just transfered) and a 50 Foo {PRICE}
	<immae> (I need to check that)
	<immae> https://paste.ee/p/VizxG [08:07]
	<immae> yep
	<immae> In this example, at the end your Broker2 has 10.00 Foo, and you Broker1 has -10.0 Foo + 10.0 Foo {150.00 EUR} + 5.0 Foo {100.00 EUR}
	[08:08]
	<immae> https://paste.ee/p/oTU6r sorry (typo) [08:09]
	<immae> so three distinct commodities [08:10]
	<sm> yes.. [08:12]
	<immae> This is expected and normal
	<immae> (from my point of view at least)
	<sm> so if you use --lot-prices, you had better always provide a lot selector when withdrawing priced amounts
	[08:13]
	<immae> yes [08:14]
	<immae> And to get away from tax penalties you'd better use them too
	[08:15]
	<immae> (and know how your country consider commodity sales)
	<sm> indeed, it was informative how you contrasted the US and France policy (longest held vs average)
	[08:16]
	<sm> For now I find it confusing that specifying the market price applicable in a purchase and selecting the lot for a sale/transfer use the same syntax
	<sm> perhaps in a while I'll see that it makes sense [08:17]
	<sm> thanks for your helpful explanations
	<immae> You're welcome :)
	<immae> (Still stuck with my own question though :D ) [08:18]
	<sm> yes. sorry. :)
	<immae> If you can read c++, it's definitly a good idea to read the transaction parser
	<immae> This is how I learnt and understood all that [08:19]
	<sm> it seems like there should be a kind of lot transfer/sale that fails if the specified lot does not exist in the asset account
	[08:22]
	<immae> no, it will be simply negative ;) [08:23]
	<sm> I know, but.. perhaps I'm talking about a layer above ledger's free-wheeling mathematical operations
	<immae> Yes [08:24]
	<sm> because if you're just doing finance, it seems too easy to create balances with arbitrary/non-existent lots
	<sm> but without --lot-prices, maybe it all looks fine. I dunno
	<sm> This stuff is complicated [08:25]
	<immae> This is why you should have things like the US example in https://paste.ee/p/BNWVU (a "capital gain" for the difference between the selling and buying)
	<immae> without --lot-prices it looks fine
	<immae> the tax taker will be the only one pissed by that :p
	<sm> I'm sure [08:27]
	<immae> (and if you look closely at your total balance without --lot-prices you'll see that it doesn't balance to 0)
	[08:28]
	<sm> I expect I'll get the hang of this stuff when I have more need of it
	<immae> If you want to use bitcoins as a commodity (to buy stuff), You'll need to
	[08:29]
	<immae> At least in France
	<sm> noted
	<sm> while if you're just acquiring and saving them, probably not
	[08:30]
	<immae> As long as you don't sell them, you're fine
	<immae> (note that rules are country-dependent, and the differences are not negligible)
	[08:31]
	* sm nods
	* sm must get back to thinking about budgeting [08:35]
	<immae> sm: Just had an idea (valid for French accounting, then): as soon as you buy a commodity at two different prices, France taxing considers that you have only one commodity at the average price. Then, we can just make ledger take it that way: https://paste.ee/p/SYmNo
	[08:37]
	<immae> As soon as I buy a new Foo, I update all the prices to an average one
	<immae> I still don't like this 133.33333 but we're almost there
	[08:38]
	<sm> nice. Modelling the reality.
	<immae> (I wish I could squeeze the two adjustments into one transaction...)
	[08:45]
	<sm> huh.. can't you ? [08:53]
	<immae> Yes you can: https://paste.ee/p/wdSuf [08:54]
	<immae> And you can merge the adjustment in the above transaction
	[08:56]
	<immae> which makes it "one operation"
	<immae> As far as I see, {...} is not supported in hledger [09:10]
	<sm> correct, or at most it's ignored [09:11]
	<sm> I've been trying to understand this stuff well enough to add it for long time
	<sm> I'm getting some new clarity I think [09:12]
	<immae> This one doesn’t compile: https://paste.ee/p/aIrAY
	...
	<sm> I see: current hledger supports {=PRICE} (and ignores it), and rejects {PRICE}
	[09:14]
	<immae> Is it because you didn’t understand it before and thus didn’t include it, or another reason?
	[09:15]
	<sm> probably I didn't understand it, or it changed, and mainly lack of time/urgency
	[09:16]
	<immae> ok
	<sm> I'm keen on understanding/clarifying/improving the pricing syntax somehow
	<sm> maybe something could be done in ledger too [09:17]
	<immae> Now that I understood how it works, I’m quite happy by the syntax, so I think I cannot help you there
	<sm> cool
	<sm> I'm not 100% convinced I need to implement the separate {} syntax
	<immae> What do you mean? [09:18]
	<immae> With respect to @ ?
	<immae> (But I’d dream of having things like 100.0 Foo {(100 EUR / 2)}, It’s just out of my C++ skills...)
	<sm> yes. I feel like I could get the reports people care about, with @ plus some way of specifying the "lot retention" (?) strategy
	[09:19]
	<immae> It seems quite important to me to track a commodity price somewhere
	[09:21]
	<immae> Be it only for historical purposes
	<immae> ledger handles it with {..}
	<sm> I think the price that's important to remember is the purchase price. That's specified with @ and that informatino must stay with the amount (making a lot). NO ?
	[09:22]
	* sm did not mean to shout :)
	<immae> It could, sure, but then you’d have different meaning of @ depending on if you sell or buy
	<immae> Homogeneity seems important too [09:23]
	<sm> when selling, the selling price is specified with @. As usual, and symmetric with the above. No problem ?
	<immae> then how do you specify that you sold a lot of another price
	[09:24]
	<immae> You buy 2 Foo's at 10.00 EUR each, then 5 Foo's at 40.00 EUR each
	<sm> when we sell, we must specify exactly which lots were sold, that's clear
	<immae> Yes, but then you cannot specify at which price you sold them
	<immae> you need both {...} and @ to specify the lot price and the price at which you sell the lot
	[09:25]
	<sm> how should we specify the lots ? I think trying to do it by price is confusing and too limited
	<immae> with ledger you can specify a lot price {..} and/or a lot date [2000/10/12]
	<sm> we could instead have a higher level approach, eg specify the strategy required by your tax authority, and let the tool work out the details
	[09:26]
	<sm> which I think is what people actually need
	<immae> How about having different strategies in a single file?
	<sm> that could be supported
	<sm> I don't know if the strategy should be per user, per file, per commodity, per transaction..
	[09:27]
	<immae> per account?
	<sm> or that
	<immae> it could be per transaction with a default that could be defined outside
	[09:28]
	<immae> per posting*
	<sm> certainly. Ideally, just enough flexibility/complexity to meet real-world needs
	[09:30]
	<sm> how many strategies are there, I wonder ? I've heard of LIFO (US) and average (FR)
	[09:31]
	<immae> no idea
	<sm> no matter [09:32]
	* sm . o O ( a "lot" is an amount + a purchase price + a purchase date )
	[09:37]
	<immae> Yep [09:38]
	<immae> (you could still buy two lots at the same date and same price and not be able to distinguish :p )
	<immae> (if you have two broker accounts, that could make a difference in taxation :p )
	[09:39]
	<immae> (but I guess it’s not that important)