price.date, transaction.post_date and neutral time

[Wm]

On 12/02/2018 18:57, Alen Siljak wrote:
> 
> 
>> Sent: Monday, February 12, 2018 at 7:34 PM
>> From: "Wm via gnucash-devel" <gnucash-devel at gnucash.org>
>> To: gnucash-devel at lists.gnucash.org
>> Subject: Re: price.date, transaction.post_date and neutral time
>>
>> On 12/02/2018 14:27, Alen Siljak wrote:
>>>      I am currently separating the Asset Allocation logic into its own
>>>      Python package, for direct use (cli) and potential library reuse
>>>      between GnuCash Portfolio and an Android app (perhaps an add-on for
>>>      MoneyManagerEx or who knows where it leads).
>>
>> MoneyManagerEx is single entry and will never get approval in the double
>> entry community.  I like they way they do reports, but their
>> understanding of accounting is broken.
> 
> True but, as a maintainer of MMEX for Android app, I have already implemented Asset Allocation module there. The mobile app served me well for years by providing transactions in .qif files, which GnuCash also handles well. So, it remains my mobile app of choice for the moment, in combination with GnuCash.


That is interesting.  There has been quite a lot of enthusiasm for 
mobile / gnc interaction.  Have you written about this before and I 
missed it ?  If MMEX for Android is working well with gnc I think you 
should make a wiki entry and ignore my view on MMEX as an accounting app.

Aside: I am completely confused how MMEX for Android could be used for 
Asset Allocation, MMEX doesn't understand Assets and Liabilities and 
Equity!  Looking at the forums, the dev's of MMEX haven't realised that 
prices aren't available from Y! any more, etc.  Crazy.  If the MMEX for 
Android app is moving beyond MMEX itself and may be working better with 
gnc then please let us know,

> What I would like to do, is extract the AA logic from the app, implement in some platform-neutral way (python?) and use on desktop and mobile. Since it is not complex, there is no reason for GnuCash not to implement the same concept. After all, it simply takes user-set allocation and compares to the quantity of the various commodities owned, calculating their current value by using their current price. Hence the need to have Allocation and Price elements.

Asset Allocation is indeed simple, the problem is that no two people 
agree on how to do it :)

Further, most AA models are USA biased, I don't think gnc needs any more 
USA bias and any model that includes a stock allocation along the lines 
of "domestic / foreign" is rubbish if you live outside of the USA so 
let's not go there! [1]

The ledger-cli AA approach works for me because I say what my AA is and 
the sums just work. I can copy and paste the output into a spreadsheet 
and see a pie chart, I can make my AA as detailed or top down or bottom 
up as I like.  It is flexible not prescriptive.  As soon as you start 
coding any of that into an app like gnc you lose the flexibility and 
start telling people "do AA like this or that".  In essence you are 
saying "I'm right, you are wrong".  I disagree with that.

The problem is that AA is like Budgeting, we agree it should be done but 
not how or why or what the point is.  For that reason I ask that the gnc 
db is more accessible and that AA and Budgeting are ripped out of the 
main application.

Am I making sense yet?

I am arguing *strongly* that any personal view AA or Budget should 
*never* be included in the main gnc app.

>> We spoke about this before.  gnc is a bad platform for trading, end of
>> discussion.
> 
> I was not in any way referring to trading but to reusing the price database file/schema. But it seems that it would be too much trouble for such a small component so nevermind.

gnc is a bad place to start if you want a comprehensive price db

gnc uses the price db for valuing stuff.  it is *not* a good way of 
recording historic prices of commodities in general.  the purpose of the 
gnc price db is for *you* to know about *your* stuff rather than finding 
out about stuff you have never owned.

if you really want to know and keep the prices of everything (which is a 
dumb thing to desire) then get a broker account <-- they aren't cheap.

for a sanity check, I am certain the good people that maintain the code 
that allows us to get prices do *not* try to maintain a complete db of 
prices themselves.  there is, quite simply, too much information.

>>>      I'm wondering what the opinion here in the project would be about such
>>>      an idea in terms of reuse and/or tools for populating and reading the
>>>      database.
>>
>> My advice is don't go there.
> 
> I still need to read the latest available prices from somewhere. I could use GnuCash book, of course, but I hate to pollute it with a bunch of prices that don't have real use inside GnuCash anyway. Actually, I'd prefer not to download any prices into my GC book apart from the ones that are generated automatically on conversion. And even those I'd prefer to clean up from time to time.
> I believe I'll do all the price-sensitive calculations outside GC by reading from a separate database (or another source).

Prices for most traded things are available on a daily basis for free.
Immediate prices (seconds and minutes) are very expensive.
Complete historic prices can be expensive but are usually free if you 
can see beyond someone else's opinion <-- that is sometimes called 
reading the news, btw.

>>>      I will definitely be creating a separate project for this, just hoping
>>>      someone else is interested.
>>
>> There is lots of scope in other projects, I don't like people forcing
>> one to be another
> 
> Hm, that gives me a few ideas already. One thing I keep forgetting is to check if perhaps someone has a similar project already. 

I noticed that too, always good to see if someone else has done the work :)

>Or I could simply try fetching and caching the latest prices for all symbols on startup. And to support offline calculations, I'd still need to save data to a db. Something to be worked-out
My advice is to not attempt that.  There are major financial companies 
that can't keep up with moment by moment pricing, if you try you will 
lose.  Use your brain for something else.

> Anyway, it would be nice to see Asset Allocation module in GnuCash. 

As above I think it would be dreadful if AA was included in gnc.

Also, gnc doesn't have a mechanism that allows modules to be plugged in 
or not.

> The current implementation is just two tables. But I'm not sure if it would satisfy everybody right now.
> The only other AA implementation I found is in ledger 

you haven't been looking, there are hundreds of AA implementations, 
maybe you mean you haven't found many that agree with your 
preconceptions ? AA is often about preconceptions.

 > but I have not tested it properly because my exported book doesn't 
balance in ledger due to mismatch in handling capital gains transactions 
between GC and ledger. :(

Heh, you just outed yourself as a bad trader :)  A "good" trader doesn't 
care about capital gains :)

[1] relative economy size is the reason why USA based AA models fail for 
the vast majority of people that don't live in the USA, duh!

-- 
Wm