Re: [GNC-dev] pricedb policy

[John Ralls]

The hierarchy is user:price/user:xfer-dialog<-F::Q<-user:price-editor for the 
reason I explained.

One more time: No, the user:price entries in the pricedb should ***NOT*** be 
considered a lookup table to the actual prices in transactions. If you want the 
actual prices in transactions (actually splits, transactions don’t have any 
amounts or values) then *go look at the splits*. If for some reason you need to 
cache the prices then cache the prices. Don’t overload the pricedb for a 
purpose for which it’s not designed.

Regards,
John Ralls


> On May 13, 2018, at 6:19 PM, Christopher Lam  
> wrote:
> 
> Thank you.
> 
> Hence my RFC about whether "user:price" entries in pricedb should be
> considered as a lookup-table to the actual prices achieved in transactions,
> and should be subject to Check fixing. I'm sure the reports will
> then fix themselves if they can rely on pricedb being accurate.
> 
> IMHO if a transaction had documented an incorrect asset price, the
> values/amounts should be amended. If I'd overvalued my house in
> Equity:Opening Balances, I'd just go and amend the amounts.
> 
> Perhaps I'll whip out a .scm to look at the prices and (optionally) offer
> to fix any discrepancies.
> 
> In future perhaps reports can offer use pricedb entries in a customizable
> hierarchy - Finance::Quote prices, user:price, user:price-editor.
> 
> On 14 May 2018 at 00:56, David T. via gnucash-devel <
> gnucash-devel@gnucash.org> wrote:
> 
>> The ONLY way to change the value in a transaction is to change it in the
>> transaction itself—either by changing the number of shares, the actual
>> price per share, or the total amount in the transaction (and note that the
>> UI will ask you about this if you change one without changing the others).
>> The price db doesn’t and shouldn’t push changes into existing real
>> transactions.
>> 
>> Changing the valuation in a transaction based on a price db change is the
>> path to madness.
>> 
>> The price db is for reporting on potential valuation. The transactions
>> represent what actually happened. If I paid $100 for 10 shares of ABC
>> stock, it doesn’t matter that the going price for ABC on the same day is $1
>> per share—I’m still out $100 (and pretty gullible, too, I’d say).
>> 
>> David T.
>> 
>> 
>>> On May 13, 2018, at 7:20 PM, Adrien Monteleone <
>> adrien.montele...@lusfiber.net> wrote:
>>> 
>>> Christopher,
>>> 
>>> I’ll add a complication for you.
>>> 
>>> Suppose one enters a transaction and later realizes the price source was
>> not correct.
>>> 
>>> Does editing the originally generated user:price affect the transactions
>> in the register? Are they in-sync or now unrelated?
>>> 
>>> If editing user:price does not change the register, does that mean you
>> have to edit the register entries (or use correcting entries) and if so,
>> does this alter the original user:price? (or add another?)
>>> 
>>> If the two get out of sync, how do you determine what is the true source
>> to use to regenerate upon loading and Check?
>>> 
>>> Regards,
>>> Adrien
>>> 
 On May 13, 2018, at 5:34 AM, Christopher Lam 
>> wrote:
 
 Hi Devs
 
 I wish to enquire about policy on pricedb.
 
 As far as I can understand, pricedb receives entries from 3 different
 sources:
 
 1. from entering transactions into the register, if the transaction
 involves a foreign currency conversion or stock. e.g. originating
>> account
 is GBP, target currency is USD --> creates a pricedb entry GBP/USD.
>> (can't
 determine which one is deemed to be the base currency). These pricedb
 entries are tagged "user:price" or "user:xfer-dialog".
 
 2. from online sources eg alphavantage. This requires careful setup, and
 seems to create price entries for all foreign currencies / commodities,
 compared to the book currency (in my case AUD). These are tagged
 "Finance::Quote".
 
 3. entries added by the user. These are tagged "user:price-editor".
 
 From my review of code so far, pricedb entries are rather important in
 reports... an incorrect pricedb entry will lead to incorrect foreign
 currency reporting, even if the transaction contains the exact transfer
 amount.
 
 My concerns relate to (1) above. I believe these transactional prices
>> are
 always more accurate than online quotes, because they describe the exact
 prices achieved.
 
 But it's buggy, e.g. if there are 2 transactions involving GBP/USD on
>> the
 same day, the second entered price will overwrite the first. (<-
>> according
 to my last test)
 
 I'd think it would be important for accuracy that, upon book opening,
>> and
 Check, the user:price data should be *overwritten* by the actual
 prices obtained from the transactions. Moreover if there are several
 transactions involving commodities, Check should **add** relevant
 amounts to 

Re: [GNC-dev] pricedb policy

[Christopher Lam]

Thank you.

Hence my RFC about whether "user:price" entries in pricedb should be
considered as a lookup-table to the actual prices achieved in transactions,
and should be subject to Check fixing. I'm sure the reports will
then fix themselves if they can rely on pricedb being accurate.

IMHO if a transaction had documented an incorrect asset price, the
values/amounts should be amended. If I'd overvalued my house in
Equity:Opening Balances, I'd just go and amend the amounts.

Perhaps I'll whip out a .scm to look at the prices and (optionally) offer
to fix any discrepancies.

In future perhaps reports can offer use pricedb entries in a customizable
hierarchy - Finance::Quote prices, user:price, user:price-editor.

On 14 May 2018 at 00:56, David T. via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> The ONLY way to change the value in a transaction is to change it in the
> transaction itself—either by changing the number of shares, the actual
> price per share, or the total amount in the transaction (and note that the
> UI will ask you about this if you change one without changing the others).
> The price db doesn’t and shouldn’t push changes into existing real
> transactions.
>
> Changing the valuation in a transaction based on a price db change is the
> path to madness.
>
> The price db is for reporting on potential valuation. The transactions
> represent what actually happened. If I paid $100 for 10 shares of ABC
> stock, it doesn’t matter that the going price for ABC on the same day is $1
> per share—I’m still out $100 (and pretty gullible, too, I’d say).
>
> David T.
>
>
> > On May 13, 2018, at 7:20 PM, Adrien Monteleone <
> adrien.montele...@lusfiber.net> wrote:
> >
> > Christopher,
> >
> > I’ll add a complication for you.
> >
> > Suppose one enters a transaction and later realizes the price source was
> not correct.
> >
> > Does editing the originally generated user:price affect the transactions
> in the register? Are they in-sync or now unrelated?
> >
> > If editing user:price does not change the register, does that mean you
> have to edit the register entries (or use correcting entries) and if so,
> does this alter the original user:price? (or add another?)
> >
> > If the two get out of sync, how do you determine what is the true source
> to use to regenerate upon loading and Check?
> >
> > Regards,
> > Adrien
> >
> >> On May 13, 2018, at 5:34 AM, Christopher Lam 
> wrote:
> >>
> >> Hi Devs
> >>
> >> I wish to enquire about policy on pricedb.
> >>
> >> As far as I can understand, pricedb receives entries from 3 different
> >> sources:
> >>
> >> 1. from entering transactions into the register, if the transaction
> >> involves a foreign currency conversion or stock. e.g. originating
> account
> >> is GBP, target currency is USD --> creates a pricedb entry GBP/USD.
> (can't
> >> determine which one is deemed to be the base currency). These pricedb
> >> entries are tagged "user:price" or "user:xfer-dialog".
> >>
> >> 2. from online sources eg alphavantage. This requires careful setup, and
> >> seems to create price entries for all foreign currencies / commodities,
> >> compared to the book currency (in my case AUD). These are tagged
> >> "Finance::Quote".
> >>
> >> 3. entries added by the user. These are tagged "user:price-editor".
> >>
> >> From my review of code so far, pricedb entries are rather important in
> >> reports... an incorrect pricedb entry will lead to incorrect foreign
> >> currency reporting, even if the transaction contains the exact transfer
> >> amount.
> >>
> >> My concerns relate to (1) above. I believe these transactional prices
> are
> >> always more accurate than online quotes, because they describe the exact
> >> prices achieved.
> >>
> >> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on
> the
> >> same day, the second entered price will overwrite the first. (<-
> according
> >> to my last test)
> >>
> >> I'd think it would be important for accuracy that, upon book opening,
> and
> >> Check, the user:price data should be *overwritten* by the actual
> >> prices obtained from the transactions. Moreover if there are several
> >> transactions involving commodities, Check should **add** relevant
> >> amounts to ensure accurate pricing.
> >>
> >> e.g.
> >> 01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
> >> 01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)
> >>
> >> should generate a price for "200 GBP to 302 USD -> pricing 1.51 USD/GBP)
> >>
> >> Unfortunately I don't do C so cannot help with coding, but would think
> that*
> >> the "user:price" prices should *always* be regenerated from the
> transaction
> >> amounts during Check & Repair and upon loading datafile.*
> >>
> >> Thoughts?
> >> ___
> >> gnucash-devel mailing list
> >> gnucash-devel@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >>
> >
> >
> > 

Re: [GNC-dev] Bug 795653 - Windows File Open/Save Dialog

[John Ralls]

Finally got the bisect done and it's 
https://gitlab.gnome.org/GNOME/glib/commit/53bd6a359f2c48e7729f89902097c892c8aa6fea,
  W32: Add a stat() implementation for private use. Next is figuring out if the 
implementation has a problem or if GtkFileChooser should be using the new 
functions.

Regards,
John Ralls


> On May 10, 2018, at 12:59 PM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> John,
> 
> I think I downgraded gtk and ran gnucash from the install directory with no 
> change. Did glib and when starting gnucash complained about pango.
> I did not rebuild gnucash after just doing gtk, I can check on that tomorrow 
> if you would like.
> 
> Bob 
> 
> On 10 May 2018 at 17:41, John Ralls  wrote:
> 
> 
> > On May 10, 2018, at 9:34 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> > 
> > Had a poke at this as I was certain that it was working in the 2.7.x series.
> > 
> > It can be fixed by downgrading the following packages with pcman -U to...
> > 
> > pacman -U
> > /var/cache/pacman/pkg/mingw-w64-i686-glib2-2.54.3-1-any.pkg.tar.xz
> > pacman -U
> > /var/cache/pacman/pkg/mingw-w64-i686-pango-1.40.11-1-any.pkg.tar.xz
> > pacman -U
> > /var/cache/pacman/pkg/mingw-w64-i686-gtk3-3.22.28-1-any.pkg.tar.xz
> > 
> > I did try doing a system upgrade with pacman -Syu but with those packages I
> > still had to down grade to the above packages to fix the file chooser
> > dialogue.
> 
> Ah, thanks, that was next on my list. Surely one need downgrade only gtk. Did 
> pacman refuse to do that if you didn't also downgrade the other two?
> 
> Regards,
> John Ralls
> 
> 

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] pricedb policy

[David T. via gnucash-devel]

The ONLY way to change the value in a transaction is to change it in the 
transaction itself—either by changing the number of shares, the actual price 
per share, or the total amount in the transaction (and note that the UI will 
ask you about this if you change one without changing the others). The price db 
doesn’t and shouldn’t push changes into existing real transactions.

Changing the valuation in a transaction based on a price db change is the path 
to madness.

The price db is for reporting on potential valuation. The transactions 
represent what actually happened. If I paid $100 for 10 shares of ABC stock, it 
doesn’t matter that the going price for ABC on the same day is $1 per share—I’m 
still out $100 (and pretty gullible, too, I’d say).

David T.


> On May 13, 2018, at 7:20 PM, Adrien Monteleone 
>  wrote:
> 
> Christopher,
> 
> I’ll add a complication for you.
> 
> Suppose one enters a transaction and later realizes the price source was not 
> correct.
> 
> Does editing the originally generated user:price affect the transactions in 
> the register? Are they in-sync or now unrelated?
> 
> If editing user:price does not change the register, does that mean you have 
> to edit the register entries (or use correcting entries) and if so, does this 
> alter the original user:price? (or add another?)
> 
> If the two get out of sync, how do you determine what is the true source to 
> use to regenerate upon loading and Check?
> 
> Regards,
> Adrien
> 
>> On May 13, 2018, at 5:34 AM, Christopher Lam  
>> wrote:
>> 
>> Hi Devs
>> 
>> I wish to enquire about policy on pricedb.
>> 
>> As far as I can understand, pricedb receives entries from 3 different
>> sources:
>> 
>> 1. from entering transactions into the register, if the transaction
>> involves a foreign currency conversion or stock. e.g. originating account
>> is GBP, target currency is USD --> creates a pricedb entry GBP/USD. (can't
>> determine which one is deemed to be the base currency). These pricedb
>> entries are tagged "user:price" or "user:xfer-dialog".
>> 
>> 2. from online sources eg alphavantage. This requires careful setup, and
>> seems to create price entries for all foreign currencies / commodities,
>> compared to the book currency (in my case AUD). These are tagged
>> "Finance::Quote".
>> 
>> 3. entries added by the user. These are tagged "user:price-editor".
>> 
>> From my review of code so far, pricedb entries are rather important in
>> reports... an incorrect pricedb entry will lead to incorrect foreign
>> currency reporting, even if the transaction contains the exact transfer
>> amount.
>> 
>> My concerns relate to (1) above. I believe these transactional prices are
>> always more accurate than online quotes, because they describe the exact
>> prices achieved.
>> 
>> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
>> same day, the second entered price will overwrite the first. (<- according
>> to my last test)
>> 
>> I'd think it would be important for accuracy that, upon book opening, and
>> Check, the user:price data should be *overwritten* by the actual
>> prices obtained from the transactions. Moreover if there are several
>> transactions involving commodities, Check should **add** relevant
>> amounts to ensure accurate pricing.
>> 
>> e.g.
>> 01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
>> 01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)
>> 
>> should generate a price for "200 GBP to 302 USD -> pricing 1.51 USD/GBP)
>> 
>> Unfortunately I don't do C so cannot help with coding, but would think that*
>> the "user:price" prices should *always* be regenerated from the transaction
>> amounts during Check & Repair and upon loading datafile.*
>> 
>> Thoughts?
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> 
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] pricedb policy

[John Ralls]

Just get local currency at a bank or from a bank’s (preferably indoor) 
ATM--don’t forget to check it for a skimmer, even if it is in the bank’s lobby. 
Make a “cash in wallet” account in the local currency. That will get you better 
rates and only a few exchange transactions.

Regards,
John Ralls



> On May 13, 2018, at 8:44 AM, Adrien Monteleone 
>  wrote:
> 
> I didn’t think of that one. Pondering that accounting nightmare makes me glad 
> I wasn’t concerned with accounting last time I was out of country and 
> shopping in just such a fashion. Most of the time even receipts weren’t 
> available. I probably paid a different exchange rate at each vendor. (It’s 
> harder than many think to keep fractional rates in your head and do math with 
> them while making purchasing decisions if you’re not used to doing so.)
> 
> Regards,
> Adrien
> 
>> On May 13, 2018, at 9:44 AM, Alen Siljak  wrote:
>> 
>> I'll add a simple case that maybe does not happen often in real accounting 
>> but happens to me all the time.
>> 
>> When traveling and exchanging cash at various small shops, the exchange rate 
>> varies wildly. This, however, should not have the precedence compared to the 
>> official central bank's rate. Also, what happens when the currency is 
>> exchanged a few times per day?
>> 
>> These are the negative side-effects of your proposal. It is, however a very 
>> valid question if the reports are using only one rate.
>> 
>> In that case, I would prefer to be in control of the rate used. 
>> 
>> Another important item is that the Australian Tax Office, for example, 
>> publishes the official exchange rates for the tax year and I would really 
>> need to be able to use that rate for all my tax reports, irrespective of 
>> what the other entered prices may be.
>> 
>>> Sent: Sunday, May 13, 2018 at 12:34 PM
>>> From: "Christopher Lam" 
>>> To: gnucash-devel@gnucash.org
>>> Subject: [GNC-dev] pricedb policy
>>> 
>>> My concerns relate to (1) above. I believe these transactional prices are
>>> always more accurate than online quotes, because they describe the exact
>>> prices achieved.
>>> 
>>> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
>>> same day, the second entered price will overwrite the first. (<- according
>>> to my last test)
>>> 
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> 
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] pricedb policy

[David Carlson]

There are two use cases that will be more common.   One is the general
end-of-period valuation that is usually driven by publicly reported prices.
  The other would be a book value which could be a cost basis.  That might
be driven by transactions or average costs.

There needs to be a way for users to design their report for  either of
these or other cases as well.

David C

On Sun, May 13, 2018, 11:39 AM Adrien Monteleone <
adrien.montele...@lusfiber.net> wrote:

> On the contrary, there is such a thing.
>
> Certainly, in near real-time, as you describe, no there isn’t.
>
> But when booking an existing asset at current market prices when starting
> a book, there is. There might be various reasons for this approach, not the
> least of which is that the original actual price paid in the home currency
> is no longer available. (and not relevant to any balancing with other
> accounts - this will balance with Equity:Opening Balances)
>
> And I was able to edit the ‘first’ user:price. So if it is supposed to be
> read-only, it’s not. (or at least wasn’t in 2.6.19)
>
> Regards,
> Adrien
>
> > On May 13, 2018, at 9:42 AM, Christopher Lam 
> wrote:
> >
> > I'm sorry there's no complication.
> >
> > There's no such thing as "price source was not correct" while entering a
> transaction.
> >
> > Let's say I transfer 100 GBP to 150 USD, currently generating a pricedb
> entry of GBP/USD=1.5, later "realize" the price source was incorrect and
> should have been GBP/USD=1.6, it would mean that the USD expense or account
> would not have received $150USD in the first place, causing all sorts of
> USD imbalances or incomplete funds for purchase.
> >
> > My view is that "user:price"-type pricedb entries are usually directly
> generated from transactional transfers, therefore can be considered a
> lookup-table for existing transfers, and should not be user-editable.
> >
> >
> > On 13/05/18 22:20, Adrien Monteleone wrote:
> >> Christopher,
> >>
> >> I’ll add a complication for you.
> >>
> >> Suppose one enters a transaction and later realizes the price source
> was not correct.
> >>
> >> Does editing the originally generated user:price affect the
> transactions in the register? Are they in-sync or now unrelated?
> >>
> >> If editing user:price does not change the register, does that mean you
> have to edit the register entries (or use correcting entries) and if so,
> does this alter the original user:price? (or add another?)
> >>
> >> If the two get out of sync, how do you determine what is the true
> source to use to regenerate upon loading and Check?
> >>
> >> Regards,
> >> Adrien
> >>
> >>> On May 13, 2018, at 5:34 AM, Christopher Lam <
> christopher@gmail.com> wrote:
> >>>
> >>> Hi Devs
> >>>
> >>> I wish to enquire about policy on pricedb.
> >>>
> >>> As far as I can understand, pricedb receives entries from 3 different
> >>> sources:
> >>>
> >>> 1. from entering transactions into the register, if the transaction
> >>> involves a foreign currency conversion or stock. e.g. originating
> account
> >>> is GBP, target currency is USD --> creates a pricedb entry GBP/USD.
> (can't
> >>> determine which one is deemed to be the base currency). These pricedb
> >>> entries are tagged "user:price" or "user:xfer-dialog".
> >>>
> >>> 2. from online sources eg alphavantage. This requires careful setup,
> and
> >>> seems to create price entries for all foreign currencies / commodities,
> >>> compared to the book currency (in my case AUD). These are tagged
> >>> "Finance::Quote".
> >>>
> >>> 3. entries added by the user. These are tagged "user:price-editor".
> >>>
> >>> From my review of code so far, pricedb entries are rather important in
> >>> reports... an incorrect pricedb entry will lead to incorrect foreign
> >>> currency reporting, even if the transaction contains the exact transfer
> >>> amount.
> >>>
> >>> My concerns relate to (1) above. I believe these transactional prices
> are
> >>> always more accurate than online quotes, because they describe the
> exact
> >>> prices achieved.
> >>>
> >>> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on
> the
> >>> same day, the second entered price will overwrite the first. (<-
> according
> >>> to my last test)
> >>>
> >>> I'd think it would be important for accuracy that, upon book opening,
> and
> >>> Check, the user:price data should be *overwritten* by the actual
> >>> prices obtained from the transactions. Moreover if there are several
> >>> transactions involving commodities, Check should **add**
> relevant
> >>> amounts to ensure accurate pricing.
> >>>
> >>> e.g.
> >>> 01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
> >>> 01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)
> >>>
> >>> should generate a price for "200 GBP to 302 USD -> pricing 1.51
> USD/GBP)
> >>>
> >>> Unfortunately I don't do C so cannot help with coding, but would think
> that*
> >>> the "user:price" prices should 

Re: [GNC-dev] pricedb policy

[Adrien Monteleone]

I didn’t think of that one. Pondering that accounting nightmare makes me glad I 
wasn’t concerned with accounting last time I was out of country and shopping in 
just such a fashion. Most of the time even receipts weren’t available. I 
probably paid a different exchange rate at each vendor. (It’s harder than many 
think to keep fractional rates in your head and do math with them while making 
purchasing decisions if you’re not used to doing so.)

Regards,
Adrien

> On May 13, 2018, at 9:44 AM, Alen Siljak  wrote:
> 
> I'll add a simple case that maybe does not happen often in real accounting 
> but happens to me all the time.
> 
> When traveling and exchanging cash at various small shops, the exchange rate 
> varies wildly. This, however, should not have the precedence compared to the 
> official central bank's rate. Also, what happens when the currency is 
> exchanged a few times per day?
> 
> These are the negative side-effects of your proposal. It is, however a very 
> valid question if the reports are using only one rate.
> 
> In that case, I would prefer to be in control of the rate used. 
> 
> Another important item is that the Australian Tax Office, for example, 
> publishes the official exchange rates for the tax year and I would really 
> need to be able to use that rate for all my tax reports, irrespective of what 
> the other entered prices may be.
> 
>> Sent: Sunday, May 13, 2018 at 12:34 PM
>> From: "Christopher Lam" 
>> To: gnucash-devel@gnucash.org
>> Subject: [GNC-dev] pricedb policy
>> 
>> My concerns relate to (1) above. I believe these transactional prices are
>> always more accurate than online quotes, because they describe the exact
>> prices achieved.
>> 
>> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
>> same day, the second entered price will overwrite the first. (<- according
>> to my last test)
>> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] pricedb policy

[Adrien Monteleone]

On the contrary, there is such a thing.

Certainly, in near real-time, as you describe, no there isn’t.

But when booking an existing asset at current market prices when starting a 
book, there is. There might be various reasons for this approach, not the least 
of which is that the original actual price paid in the home currency is no 
longer available. (and not relevant to any balancing with other accounts - this 
will balance with Equity:Opening Balances)

And I was able to edit the ‘first’ user:price. So if it is supposed to be 
read-only, it’s not. (or at least wasn’t in 2.6.19)

Regards,
Adrien

> On May 13, 2018, at 9:42 AM, Christopher Lam  
> wrote:
> 
> I'm sorry there's no complication.
> 
> There's no such thing as "price source was not correct" while entering a 
> transaction.
> 
> Let's say I transfer 100 GBP to 150 USD, currently generating a pricedb entry 
> of GBP/USD=1.5, later "realize" the price source was incorrect and should 
> have been GBP/USD=1.6, it would mean that the USD expense or account would 
> not have received $150USD in the first place, causing all sorts of USD 
> imbalances or incomplete funds for purchase.
> 
> My view is that "user:price"-type pricedb entries are usually directly 
> generated from transactional transfers, therefore can be considered a 
> lookup-table for existing transfers, and should not be user-editable.
> 
> 
> On 13/05/18 22:20, Adrien Monteleone wrote:
>> Christopher,
>> 
>> I’ll add a complication for you.
>> 
>> Suppose one enters a transaction and later realizes the price source was not 
>> correct.
>> 
>> Does editing the originally generated user:price affect the transactions in 
>> the register? Are they in-sync or now unrelated?
>> 
>> If editing user:price does not change the register, does that mean you have 
>> to edit the register entries (or use correcting entries) and if so, does 
>> this alter the original user:price? (or add another?)
>> 
>> If the two get out of sync, how do you determine what is the true source to 
>> use to regenerate upon loading and Check?
>> 
>> Regards,
>> Adrien
>> 
>>> On May 13, 2018, at 5:34 AM, Christopher Lam  
>>> wrote:
>>> 
>>> Hi Devs
>>> 
>>> I wish to enquire about policy on pricedb.
>>> 
>>> As far as I can understand, pricedb receives entries from 3 different
>>> sources:
>>> 
>>> 1. from entering transactions into the register, if the transaction
>>> involves a foreign currency conversion or stock. e.g. originating account
>>> is GBP, target currency is USD --> creates a pricedb entry GBP/USD. (can't
>>> determine which one is deemed to be the base currency). These pricedb
>>> entries are tagged "user:price" or "user:xfer-dialog".
>>> 
>>> 2. from online sources eg alphavantage. This requires careful setup, and
>>> seems to create price entries for all foreign currencies / commodities,
>>> compared to the book currency (in my case AUD). These are tagged
>>> "Finance::Quote".
>>> 
>>> 3. entries added by the user. These are tagged "user:price-editor".
>>> 
>>> From my review of code so far, pricedb entries are rather important in
>>> reports... an incorrect pricedb entry will lead to incorrect foreign
>>> currency reporting, even if the transaction contains the exact transfer
>>> amount.
>>> 
>>> My concerns relate to (1) above. I believe these transactional prices are
>>> always more accurate than online quotes, because they describe the exact
>>> prices achieved.
>>> 
>>> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
>>> same day, the second entered price will overwrite the first. (<- according
>>> to my last test)
>>> 
>>> I'd think it would be important for accuracy that, upon book opening, and
>>> Check, the user:price data should be *overwritten* by the actual
>>> prices obtained from the transactions. Moreover if there are several
>>> transactions involving commodities, Check should **add** relevant
>>> amounts to ensure accurate pricing.
>>> 
>>> e.g.
>>> 01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
>>> 01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)
>>> 
>>> should generate a price for "200 GBP to 302 USD -> pricing 1.51 USD/GBP)
>>> 
>>> Unfortunately I don't do C so cannot help with coding, but would think that*
>>> the "user:price" prices should *always* be regenerated from the transaction
>>> amounts during Check & Repair and upon loading datafile.*
>>> 
>>> Thoughts?
>>> ___
>>> gnucash-devel mailing list
>>> gnucash-devel@gnucash.org
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>> 
>> 
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> 

Re: [GNC-dev] pricedb policy

[John Ralls]

> On May 13, 2018, at 3:34 AM, Christopher Lam  
> wrote:
> 
> Hi Devs
> 
> I wish to enquire about policy on pricedb.
> 
> As far as I can understand, pricedb receives entries from 3 different
> sources:
> 
> 1. from entering transactions into the register, if the transaction
> involves a foreign currency conversion or stock. e.g. originating account
> is GBP, target currency is USD --> creates a pricedb entry GBP/USD. (can't
> determine which one is deemed to be the base currency). These pricedb
> entries are tagged "user:price" or "user:xfer-dialog".
> 
> 2. from online sources eg alphavantage. This requires careful setup, and
> seems to create price entries for all foreign currencies / commodities,
> compared to the book currency (in my case AUD). These are tagged
> "Finance::Quote".
> 
> 3. entries added by the user. These are tagged "user:price-editor".
> 
> From my review of code so far, pricedb entries are rather important in
> reports... an incorrect pricedb entry will lead to incorrect foreign
> currency reporting, even if the transaction contains the exact transfer
> amount.
> 
> My concerns relate to (1) above. I believe these transactional prices are
> always more accurate than online quotes, because they describe the exact
> prices achieved.
> 
> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
> same day, the second entered price will overwrite the first. (<- according
> to my last test)
> 
> I'd think it would be important for accuracy that, upon book opening, and
> Check, the user:price data should be *overwritten* by the actual
> prices obtained from the transactions. Moreover if there are several
> transactions involving commodities, Check should **add** relevant
> amounts to ensure accurate pricing.
> 
> e.g.
> 01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
> 01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)
> 
> should generate a price for "200 GBP to 302 USD -> pricing 1.51 USD/GBP)
> 
> Unfortunately I don't do C so cannot help with coding, but would think that*
> the "user:price" prices should *always* be regenerated from the transaction
> amounts during Check & Repair and upon loading datafile.*
> 


All of which would be nullified if there’s a higher-precedence (F::Q or 
price-editor) price in the database.

The price database is intended to provide a current market price for the 
Accounts page, the summary bar, and the balance sheet (for unrealized 
gain/loss), and a set of historical prices for the time-series charts. In 
general practice the preferred price is the closing price on any day in the 
past or the last trade for today if the market is open, and that’s why F::Q 
overwrites user:price and user:xfer-dialog. Of course getting that requires the 
user to run F::Q after the close each day and few do. I added the user and 
xfer-dialog price entries a few years ago so that  there would be some price in 
the pricedb if the user doesn’t run F::Q.

If you want book values for a report, use Average Cost as the report’s price 
source: That’s calculated from the splits using the amount and value--though it 
needs some work, see https://bugzilla.gnome.org/show_bug.cgi?id=775368 
.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] pricedb policy

[Alen Siljak]

I'll add a simple case that maybe does not happen often in real accounting but 
happens to me all the time.

When traveling and exchanging cash at various small shops, the exchange rate 
varies wildly. This, however, should not have the precedence compared to the 
official central bank's rate. Also, what happens when the currency is exchanged 
a few times per day?

These are the negative side-effects of your proposal. It is, however a very 
valid question if the reports are using only one rate.

In that case, I would prefer to be in control of the rate used. 

Another important item is that the Australian Tax Office, for example, 
publishes the official exchange rates for the tax year and I would really need 
to be able to use that rate for all my tax reports, irrespective of what the 
other entered prices may be.

> Sent: Sunday, May 13, 2018 at 12:34 PM
> From: "Christopher Lam" 
> To: gnucash-devel@gnucash.org
> Subject: [GNC-dev] pricedb policy
> 
> My concerns relate to (1) above. I believe these transactional prices are
> always more accurate than online quotes, because they describe the exact
> prices achieved.
> 
> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
> same day, the second entered price will overwrite the first. (<- according
> to my last test)
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] pricedb policy

[Christopher Lam]

I'm sorry there's no complication.

There's no such thing as "price source was not correct" while entering a 
transaction.


Let's say I transfer 100 GBP to 150 USD, currently generating a pricedb 
entry of GBP/USD=1.5, later "realize" the price source was incorrect and 
should have been GBP/USD=1.6, it would mean that the USD expense or 
account would not have received $150USD in the first place, causing all 
sorts of USD imbalances or incomplete funds for purchase.


My view is that "user:price"-type pricedb entries are usually directly 
generated from transactional transfers, therefore can be considered a 
lookup-table for existing transfers, and should not be user-editable.



On 13/05/18 22:20, Adrien Monteleone wrote:

Christopher,

I’ll add a complication for you.

Suppose one enters a transaction and later realizes the price source was not 
correct.

Does editing the originally generated user:price affect the transactions in the 
register? Are they in-sync or now unrelated?

If editing user:price does not change the register, does that mean you have to 
edit the register entries (or use correcting entries) and if so, does this 
alter the original user:price? (or add another?)

If the two get out of sync, how do you determine what is the true source to use to 
regenerate upon loading and Check?

Regards,
Adrien


On May 13, 2018, at 5:34 AM, Christopher Lam  wrote:

Hi Devs

I wish to enquire about policy on pricedb.

As far as I can understand, pricedb receives entries from 3 different
sources:

1. from entering transactions into the register, if the transaction
involves a foreign currency conversion or stock. e.g. originating account
is GBP, target currency is USD --> creates a pricedb entry GBP/USD. (can't
determine which one is deemed to be the base currency). These pricedb
entries are tagged "user:price" or "user:xfer-dialog".

2. from online sources eg alphavantage. This requires careful setup, and
seems to create price entries for all foreign currencies / commodities,
compared to the book currency (in my case AUD). These are tagged
"Finance::Quote".

3. entries added by the user. These are tagged "user:price-editor".

 From my review of code so far, pricedb entries are rather important in
reports... an incorrect pricedb entry will lead to incorrect foreign
currency reporting, even if the transaction contains the exact transfer
amount.

My concerns relate to (1) above. I believe these transactional prices are
always more accurate than online quotes, because they describe the exact
prices achieved.

But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
same day, the second entered price will overwrite the first. (<- according
to my last test)

I'd think it would be important for accuracy that, upon book opening, and
Check, the user:price data should be *overwritten* by the actual
prices obtained from the transactions. Moreover if there are several
transactions involving commodities, Check should **add** relevant
amounts to ensure accurate pricing.

e.g.
01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)

should generate a price for "200 GBP to 302 USD -> pricing 1.51 USD/GBP)

Unfortunately I don't do C so cannot help with coding, but would think that*
the "user:price" prices should *always* be regenerated from the transaction
amounts during Check & Repair and upon loading datafile.*

Thoughts?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] pricedb policy

[Adrien Monteleone]

Christopher,

I’ll add a complication for you.

Suppose one enters a transaction and later realizes the price source was not 
correct.

Does editing the originally generated user:price affect the transactions in the 
register? Are they in-sync or now unrelated?

If editing user:price does not change the register, does that mean you have to 
edit the register entries (or use correcting entries) and if so, does this 
alter the original user:price? (or add another?)

If the two get out of sync, how do you determine what is the true source to use 
to regenerate upon loading and Check?

Regards,
Adrien

> On May 13, 2018, at 5:34 AM, Christopher Lam  
> wrote:
> 
> Hi Devs
> 
> I wish to enquire about policy on pricedb.
> 
> As far as I can understand, pricedb receives entries from 3 different
> sources:
> 
> 1. from entering transactions into the register, if the transaction
> involves a foreign currency conversion or stock. e.g. originating account
> is GBP, target currency is USD --> creates a pricedb entry GBP/USD. (can't
> determine which one is deemed to be the base currency). These pricedb
> entries are tagged "user:price" or "user:xfer-dialog".
> 
> 2. from online sources eg alphavantage. This requires careful setup, and
> seems to create price entries for all foreign currencies / commodities,
> compared to the book currency (in my case AUD). These are tagged
> "Finance::Quote".
> 
> 3. entries added by the user. These are tagged "user:price-editor".
> 
> From my review of code so far, pricedb entries are rather important in
> reports... an incorrect pricedb entry will lead to incorrect foreign
> currency reporting, even if the transaction contains the exact transfer
> amount.
> 
> My concerns relate to (1) above. I believe these transactional prices are
> always more accurate than online quotes, because they describe the exact
> prices achieved.
> 
> But it's buggy, e.g. if there are 2 transactions involving GBP/USD on the
> same day, the second entered price will overwrite the first. (<- according
> to my last test)
> 
> I'd think it would be important for accuracy that, upon book opening, and
> Check, the user:price data should be *overwritten* by the actual
> prices obtained from the transactions. Moreover if there are several
> transactions involving commodities, Check should **add** relevant
> amounts to ensure accurate pricing.
> 
> e.g.
> 01/01/2018 Transfer 100 GBP to 150 USD (generates pricing 1.5 USD/GBP)
> 01/01/2018 Transfer 100 GBP to 152 USD (generates pricing 1.52 USD/GBP)
> 
> should generate a price for "200 GBP to 302 USD -> pricing 1.51 USD/GBP)
> 
> Unfortunately I don't do C so cannot help with coding, but would think that*
> the "user:price" prices should *always* be regenerated from the transaction
> amounts during Check & Repair and upon loading datafile.*
> 
> Thoughts?
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel