Re: trial balance - how to find mismatch question

[Wm via gnucash-devel]

On 16/02/2018 08:20, Adrien Monteleone wrote:

At least on my version of the Trial Balance report, there is no ‘Imbalance 
entry’ specifically.

There is at the bottom, the Imbalance-XXX and Orphan-XXX accounts listed along 
with the others.

There is also a line for ‘Unrealized Gains’ or ‘Unrealized Losses’ (I have the 
latter, even though the report duration was a single day with no price changes, 
I gave up trying to figure that one out)

The ‘imbalance’ I’m speaking of trying to resolve, or at least finally attributed 
to a rounding error with the XAG account, was simply the difference between what 
the report shows as Total Debits & Total Credits. (note, these aren’t labeled 
as such on the report - but they appear at the bottom, and that’s clearly what they 
are) There is no figure on the report that shows this difference. I had to 
calculate it manually. When I decided to audit the report for each account is when 
I found the foreign currency account out of whack. The remaining difference was 
attributable entirely to the ‘unrealized losses’ line.

So, the full difference between debits and credits is the SUM of the 
‘Unrealized Gains/Losses’ line and the discrepancy due to rounding.

At least in my case.



I'm liking your approach to things, AdrienM.  So try this:

Make a copy of your book for safe keeping.

Go to File / Properties and if it is ticked (checked in american) untick 
it, my guess is it will be unticked (unchecked) so you will be about to 
enter the world of trading accounts.


I love them for what they do and since there is a discussion in another 
thread about naming things like the General Ledger or Journal, think 
"Trading accounts" is a bad name.  Who cares about a word?  Welcome to 
some marvellous accounting :)


Onwards.

Close your book and open it again

Actions / Check & repair. [1]

[1] if you are using business accounts you might need to run Check & 
repair on individual accounts as there was a problem there and I can't 
recall exactly if it has been fixed or not, but no harm done in double 
checking. You only need to do this extra step for accounts that have a 
type of A/Receivable or A/Payable, my understanding is all other 
accounts are covered by the general check.


You should now have an extra top level account called Trading [2]

[2] it is badly named (but I think people that use it are used to the 
name now) and arguably badly positioned in the account tree as it 
belongs in Equity in accounting terms so keep that in mind.


Open the Trading account and explore a bit.  All the differences you 
were wondering about should be there and you should be able to delete 
the Imbalance, Orphan, et al accounts as they should be empty unless you 
really have entered an imbalanced tx <-- everyone makes a mistake sometimes.




So there are two problems with the report:

1) There should be no losses or gains if there were no trading transactions. 
Certainly, this is impossible if there is only one day on the range of the 
report and the price is the same. If all you have are opening entries and you 
attempt to run a trial balance for that same day, you can’t have either a gain 
or a loss, unrealized or not.



Watch out for the use of the word "trading" it is idiosyncratic in gnc.


2) Because the Equity:Opening Balances account is the result of rounded figures 
for each entry in a foreign currency, the report’s method of taking the foreign 
currency ending balance as of a date and doing the exchange rate calculation at 
the end, will always produce a discrepancy. The report would have to sum the 
book-default currency amounts individually or somehow a book-default currency 
balance would have to be maintained and that used instead. Alternatively, a 
foreign currency account could use the same precision as the foreign currency 
itself, thus removing the potential for rounding errors if not eliminating them.



I think I have already answered this [3] but live multi-commodity TB 
work is not for the faint hearted and generally isn't necessary unless 
someone has taken a position on the movement of currencies or 
commodities against each other and is making it their business.


[3] it may have been modded, I don't double check unless it is obvious 
something hasn't got through.



Possibly, increasing the decimal places and re-entering the transactions for 
the XAG account might resolve the rounding issue. (only because now the USD 
amounts sum correctly to match since they don’t round enough) But then ALL USD 
accounts would have this extra precision which is not desirable generally.



Try Trading accounts before that weirdness.


The alternative would be to reduce the precision of the XAG account, but again, 
that is undesirable for accurate tracking of ownership quantities of the actual 
metal. (or currency if that’s the case)



As above, this is what Trading accounts are for.


The per-account precision setting seems to only affect the default currency for 
that account, 

Re: trial balance - how to find mismatch question

[David Carlson]

I am not a custodian but neither do I trust my custodians to remain 100%
invulnerable to hacking, so I continue to monitor their reports and check
them for accuracy.  If all the numbers in GnuCash are correct, the GnuCash
reports can line up next to the trustees reports and usually agree to the
penny.  That makes checking a pleasant, if quixotic activity.  :-)

David C

On Tue, Mar 6, 2018 at 11:15 AM, David T.  wrote:

> BTW, quixotic, while based on the famous Don Quixote, is a non-proper
> (improper?) adjective, and thus does not need capitalization. Whether you
> pronounce it “key-hotic” or “quick-sotic” depends on your personal
> predilection, as I undetstand it.
>
> David
>
>
> On Mar 6, 2018, at 7:57 AM, David Carlson 
> wrote:
>
> David T, I guess you do not have any IRA's or 401-K's as the IRS requires
> every custodian to file either a "Fair Market Value" form or a form 5498
> which includes the fair market value for each account.  The "as of" time is
> calendar year end.
>
> When you turn 70-1/2 you get to take a "Required Minimum Distribution"
> each year based on a formula outlined in Publication 590-B which uses the
> Fair Market Value and an actuarial table.  If you do not take the RMD, you
> pay a fine and take it anyway.
>
> While I would not depend on GnuCash to make an accurate report without
> checking on every part of the data that it used to make the calculation and
> check it in an external spreadsheet where I can actually see every number,
> I like to try to verify that my custodians used the method I think they
> should use to calculate realized gains long and short where needed and to
> accurately report FMV so that my RMD is correct.
>
> I did not intend to be unwitting about the problems with getting an
> accurate balance report out of GnuCash, you are correct to call it
> Quixotic, and I would capitalize that adjective, if it is one.  In fact, I
> was trying to underline some of the issues that I have personally
> experienced.
>
> David C
>
> On Mon, Mar 5, 2018 at 8:08 PM, David T.  wrote:
>
>> David Carlson,
>>
>> > On Mar 6, 2018, at 4:27 AM, David Carlson 
>> wrote:
>> >
>> > Adrien, I think that you summarized the problem with "nearest in time"
>> > nicely.  Wm, no doubt, had tongue in cheek when he was assigning a high
>> > value to future prices.  You clarify that reports are often run "as of"
>> > historical dates (and often need to match accounting reports submitted
>> to
>> > government agencies) thus could be exposed to erroneous values assigned
>> > after the "as of" date by the "nearest in time" criterion.
>>
>> Can you clarify the reports that you submit to governmental agencies that
>> use market value? My government (the US) doesn’t require any reporting of
>> asset market value that I am aware of. As far as I know, the only reporting
>> that is required is actual, realized, gains—and not book value of holdings.
>> And as far as I understand, GnuCash doesn’t use price db entries to track
>> this information; the preferred methods (as outlined in various sources) is
>> to enter the gains literally, based on the price entered and stored in the
>> transactions.
>>
>> >
>> > Your final note that ideally the prices would always be downloaded on
>> the
>> > date they are needed for the report is true, but as a practical matter
>> it
>> > is sometimes difficult to do, as the prices are often posted on the
>> > internet several hours after the respective closing bell, and now that
>> the
>> > F:Q module is sometimes unable to acquire some prices on the first
>> pass, it
>> > is sometimes problematic whether it has even succeeded in getting all
>> the
>> > needed prices.  If it is done by a chron job, the job would need very
>> > intelligent error handling capability to be confident about success.
>>
>> Here, I think you unwittingly point to a significant problem inherent in
>> trying to track market value of even a moderate portfolio: there is no
>> means of determining the effective valuation date. If, as Adrien points
>> out, you retrieve prices monthly, then the values can be almost a month out
>> of date. If, as you point out, some prices fail to update, then some may be
>> from last week, while others from today. So, obtaining an accurate
>> valuation is a significant challenge. Perhaps this suggests that the entire
>> portfolio valuation proposal is quixotic in its goal of Absolute Valuation,
>> and should be considered only as a rough guide at best?
>>
>> David T.
>>
>>
>> >
>> > If a developer wanted to expand the scope of the price download module
>> to
>> > allow downloading "as of" prices for arbitrary historical dates, I think
>> > many of us would buy him a beer.  Alas, right now I fear that the
>> currently
>> > active developers have too many other things on their plates.
>> >
>> > David C
>> >
>>
>>
>
>
___

Re: trial balance - how to find mismatch question

[David T. via gnucash-devel]

BTW, quixotic, while based on the famous Don Quixote, is a non-proper 
(improper?) adjective, and thus does not need capitalization. Whether you 
pronounce it “key-hotic” or “quick-sotic” depends on your personal 
predilection, as I undetstand it.

David

> On Mar 6, 2018, at 7:57 AM, David Carlson  wrote:
> 
> David T, I guess you do not have any IRA's or 401-K's as the IRS requires 
> every custodian to file either a "Fair Market Value" form or a form 5498 
> which includes the fair market value for each account.  The "as of" time is 
> calendar year end.
> 
> When you turn 70-1/2 you get to take a "Required Minimum Distribution" each 
> year based on a formula outlined in Publication 590-B which uses the Fair 
> Market Value and an actuarial table.  If you do not take the RMD, you pay a 
> fine and take it anyway.
> 
> While I would not depend on GnuCash to make an accurate report without 
> checking on every part of the data that it used to make the calculation and 
> check it in an external spreadsheet where I can actually see every number, I 
> like to try to verify that my custodians used the method I think they should 
> use to calculate realized gains long and short where needed and to accurately 
> report FMV so that my RMD is correct.
> 
> I did not intend to be unwitting about the problems with getting an accurate 
> balance report out of GnuCash, you are correct to call it Quixotic, and I 
> would capitalize that adjective, if it is one.  In fact, I was trying to 
> underline some of the issues that I have personally experienced.
> 
> David C
> 
> On Mon, Mar 5, 2018 at 8:08 PM, David T.  > wrote:
> David Carlson,
> 
> > On Mar 6, 2018, at 4:27 AM, David Carlson  > > wrote:
> >
> > Adrien, I think that you summarized the problem with "nearest in time"
> > nicely.  Wm, no doubt, had tongue in cheek when he was assigning a high
> > value to future prices.  You clarify that reports are often run "as of"
> > historical dates (and often need to match accounting reports submitted to
> > government agencies) thus could be exposed to erroneous values assigned
> > after the "as of" date by the "nearest in time" criterion.
> 
> Can you clarify the reports that you submit to governmental agencies that use 
> market value? My government (the US) doesn’t require any reporting of asset 
> market value that I am aware of. As far as I know, the only reporting that is 
> required is actual, realized, gains—and not book value of holdings. And as 
> far as I understand, GnuCash doesn’t use price db entries to track this 
> information; the preferred methods (as outlined in various sources) is to 
> enter the gains literally, based on the price entered and stored in the 
> transactions.
> 
> >
> > Your final note that ideally the prices would always be downloaded on the
> > date they are needed for the report is true, but as a practical matter it
> > is sometimes difficult to do, as the prices are often posted on the
> > internet several hours after the respective closing bell, and now that the
> > F:Q module is sometimes unable to acquire some prices on the first pass, it
> > is sometimes problematic whether it has even succeeded in getting all the
> > needed prices.  If it is done by a chron job, the job would need very
> > intelligent error handling capability to be confident about success.
> 
> Here, I think you unwittingly point to a significant problem inherent in 
> trying to track market value of even a moderate portfolio: there is no means 
> of determining the effective valuation date. If, as Adrien points out, you 
> retrieve prices monthly, then the values can be almost a month out of date. 
> If, as you point out, some prices fail to update, then some may be from last 
> week, while others from today. So, obtaining an accurate valuation is a 
> significant challenge. Perhaps this suggests that the entire portfolio 
> valuation proposal is quixotic in its goal of Absolute Valuation, and should 
> be considered only as a rough guide at best?
> 
> David T.
> 
> 
> >
> > If a developer wanted to expand the scope of the price download module to
> > allow downloading "as of" prices for arbitrary historical dates, I think
> > many of us would buy him a beer.  Alas, right now I fear that the currently
> > active developers have too many other things on their plates.
> >
> > David C
> >
> 
> 

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

Re: trial balance - how to find mismatch question

[David T. via gnucash-devel]

David,

I have IRAs, but I do not *manage* IRAs. The custodian is the entity with whom 
I maintain my IRA, and so I do not need to report an IRA valuation. THEY do.

So, it is true—I do not act as custodian for others’ retirement accounts. I 
wonder whether this is common for the GnuCash user base. 

David T.

> On Mar 6, 2018, at 7:57 AM, David Carlson  wrote:
> 
> David T, I guess you do not have any IRA's or 401-K's as the IRS requires 
> every custodian to file either a "Fair Market Value" form or a form 5498 
> which includes the fair market value for each account.  The "as of" time is 
> calendar year end.
> 
> When you turn 70-1/2 you get to take a "Required Minimum Distribution" each 
> year based on a formula outlined in Publication 590-B which uses the Fair 
> Market Value and an actuarial table.  If you do not take the RMD, you pay a 
> fine and take it anyway.
> 
> While I would not depend on GnuCash to make an accurate report without 
> checking on every part of the data that it used to make the calculation and 
> check it in an external spreadsheet where I can actually see every number, I 
> like to try to verify that my custodians used the method I think they should 
> use to calculate realized gains long and short where needed and to accurately 
> report FMV so that my RMD is correct.
> 
> I did not intend to be unwitting about the problems with getting an accurate 
> balance report out of GnuCash, you are correct to call it Quixotic, and I 
> would capitalize that adjective, if it is one.  In fact, I was trying to 
> underline some of the issues that I have personally experienced.
> 
> David C
> 
> On Mon, Mar 5, 2018 at 8:08 PM, David T.  > wrote:
> David Carlson,
> 
> > On Mar 6, 2018, at 4:27 AM, David Carlson  > > wrote:
> >
> > Adrien, I think that you summarized the problem with "nearest in time"
> > nicely.  Wm, no doubt, had tongue in cheek when he was assigning a high
> > value to future prices.  You clarify that reports are often run "as of"
> > historical dates (and often need to match accounting reports submitted to
> > government agencies) thus could be exposed to erroneous values assigned
> > after the "as of" date by the "nearest in time" criterion.
> 
> Can you clarify the reports that you submit to governmental agencies that use 
> market value? My government (the US) doesn’t require any reporting of asset 
> market value that I am aware of. As far as I know, the only reporting that is 
> required is actual, realized, gains—and not book value of holdings. And as 
> far as I understand, GnuCash doesn’t use price db entries to track this 
> information; the preferred methods (as outlined in various sources) is to 
> enter the gains literally, based on the price entered and stored in the 
> transactions.
> 
> >
> > Your final note that ideally the prices would always be downloaded on the
> > date they are needed for the report is true, but as a practical matter it
> > is sometimes difficult to do, as the prices are often posted on the
> > internet several hours after the respective closing bell, and now that the
> > F:Q module is sometimes unable to acquire some prices on the first pass, it
> > is sometimes problematic whether it has even succeeded in getting all the
> > needed prices.  If it is done by a chron job, the job would need very
> > intelligent error handling capability to be confident about success.
> 
> Here, I think you unwittingly point to a significant problem inherent in 
> trying to track market value of even a moderate portfolio: there is no means 
> of determining the effective valuation date. If, as Adrien points out, you 
> retrieve prices monthly, then the values can be almost a month out of date. 
> If, as you point out, some prices fail to update, then some may be from last 
> week, while others from today. So, obtaining an accurate valuation is a 
> significant challenge. Perhaps this suggests that the entire portfolio 
> valuation proposal is quixotic in its goal of Absolute Valuation, and should 
> be considered only as a rough guide at best?
> 
> David T.
> 
> 
> >
> > If a developer wanted to expand the scope of the price download module to
> > allow downloading "as of" prices for arbitrary historical dates, I think
> > many of us would buy him a beer.  Alas, right now I fear that the currently
> > active developers have too many other things on their plates.
> >
> > David C
> >
> 
> 

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

Re: trial balance - how to find mismatch question

[Wm via gnucash-devel]

On 16/02/2018 04:55, David T. via gnucash-devel wrote:
I don’t believe I’ve seen anywhere in this thread any attempt to explain that there is a difference between IMBALANCE-XXX (an indication that you have transactions that lacked a balancing split) and the Imbalance entry in the Trial Balance report. This latter most likely indicates (as David C. has hinted) that your books have capital or currency gains or losses that haven’t been entered into the books. 


I think that's advanced for most readers of this thread.


If you buy a stock for $100 using a balanced transaction, and later sell that 
share for $150 (we wish!) in a balanced transaction, GnuCash will wonder where 
you got an additional $50. Both transactions balance, but the books don’t. That 
is why you usually have an entry (either as a separate transaction, or as 
splits in the sell transaction) that account for this gain.

Of course, it can get complex.


In pure-ish accounting terms it doesn't matter.  The IMBALANCE and 
similar are what used to be called suspense accounts.


It is, of course, good behaviour to balance tx as they happen.

And a TB is a moment in time and value of stuff will be different the 
second afterwards.



For this reason TB's (and balance sheets) are usually presumed to not be 
in the future and if dated today (which I prefer) actually not 
representing today's prices, etc if I haven't fetched them.


In plain terms: documents are interpreted and should be clear.  I think 
the prices at the bottom of a report make most things clear.


--
Wm



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

Re: trial balance - how to find mismatch question

[David Carlson]

David T, I guess you do not have any IRA's or 401-K's as the IRS requires
every custodian to file either a "Fair Market Value" form or a form 5498
which includes the fair market value for each account.  The "as of" time is
calendar year end.

When you turn 70-1/2 you get to take a "Required Minimum Distribution" each
year based on a formula outlined in Publication 590-B which uses the Fair
Market Value and an actuarial table.  If you do not take the RMD, you pay a
fine and take it anyway.

While I would not depend on GnuCash to make an accurate report without
checking on every part of the data that it used to make the calculation and
check it in an external spreadsheet where I can actually see every number,
I like to try to verify that my custodians used the method I think they
should use to calculate realized gains long and short where needed and to
accurately report FMV so that my RMD is correct.

I did not intend to be unwitting about the problems with getting an
accurate balance report out of GnuCash, you are correct to call it
Quixotic, and I would capitalize that adjective, if it is one.  In fact, I
was trying to underline some of the issues that I have personally
experienced.

David C

On Mon, Mar 5, 2018 at 8:08 PM, David T.  wrote:

> David Carlson,
>
> > On Mar 6, 2018, at 4:27 AM, David Carlson 
> wrote:
> >
> > Adrien, I think that you summarized the problem with "nearest in time"
> > nicely.  Wm, no doubt, had tongue in cheek when he was assigning a high
> > value to future prices.  You clarify that reports are often run "as of"
> > historical dates (and often need to match accounting reports submitted to
> > government agencies) thus could be exposed to erroneous values assigned
> > after the "as of" date by the "nearest in time" criterion.
>
> Can you clarify the reports that you submit to governmental agencies that
> use market value? My government (the US) doesn’t require any reporting of
> asset market value that I am aware of. As far as I know, the only reporting
> that is required is actual, realized, gains—and not book value of holdings.
> And as far as I understand, GnuCash doesn’t use price db entries to track
> this information; the preferred methods (as outlined in various sources) is
> to enter the gains literally, based on the price entered and stored in the
> transactions.
>
> >
> > Your final note that ideally the prices would always be downloaded on the
> > date they are needed for the report is true, but as a practical matter it
> > is sometimes difficult to do, as the prices are often posted on the
> > internet several hours after the respective closing bell, and now that
> the
> > F:Q module is sometimes unable to acquire some prices on the first pass,
> it
> > is sometimes problematic whether it has even succeeded in getting all the
> > needed prices.  If it is done by a chron job, the job would need very
> > intelligent error handling capability to be confident about success.
>
> Here, I think you unwittingly point to a significant problem inherent in
> trying to track market value of even a moderate portfolio: there is no
> means of determining the effective valuation date. If, as Adrien points
> out, you retrieve prices monthly, then the values can be almost a month out
> of date. If, as you point out, some prices fail to update, then some may be
> from last week, while others from today. So, obtaining an accurate
> valuation is a significant challenge. Perhaps this suggests that the entire
> portfolio valuation proposal is quixotic in its goal of Absolute Valuation,
> and should be considered only as a rough guide at best?
>
> David T.
>
>
> >
> > If a developer wanted to expand the scope of the price download module to
> > allow downloading "as of" prices for arbitrary historical dates, I think
> > many of us would buy him a beer.  Alas, right now I fear that the
> currently
> > active developers have too many other things on their plates.
> >
> > David C
> >
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: trial balance - how to find mismatch question

[David T. via gnucash-devel]

David Carlson,

> On Mar 6, 2018, at 4:27 AM, David Carlson  wrote:
> 
> Adrien, I think that you summarized the problem with "nearest in time"
> nicely.  Wm, no doubt, had tongue in cheek when he was assigning a high
> value to future prices.  You clarify that reports are often run "as of"
> historical dates (and often need to match accounting reports submitted to
> government agencies) thus could be exposed to erroneous values assigned
> after the "as of" date by the "nearest in time" criterion.

Can you clarify the reports that you submit to governmental agencies that use 
market value? My government (the US) doesn’t require any reporting of asset 
market value that I am aware of. As far as I know, the only reporting that is 
required is actual, realized, gains—and not book value of holdings. And as far 
as I understand, GnuCash doesn’t use price db entries to track this 
information; the preferred methods (as outlined in various sources) is to enter 
the gains literally, based on the price entered and stored in the transactions.

> 
> Your final note that ideally the prices would always be downloaded on the
> date they are needed for the report is true, but as a practical matter it
> is sometimes difficult to do, as the prices are often posted on the
> internet several hours after the respective closing bell, and now that the
> F:Q module is sometimes unable to acquire some prices on the first pass, it
> is sometimes problematic whether it has even succeeded in getting all the
> needed prices.  If it is done by a chron job, the job would need very
> intelligent error handling capability to be confident about success.

Here, I think you unwittingly point to a significant problem inherent in trying 
to track market value of even a moderate portfolio: there is no means of 
determining the effective valuation date. If, as Adrien points out, you 
retrieve prices monthly, then the values can be almost a month out of date. If, 
as you point out, some prices fail to update, then some may be from last week, 
while others from today. So, obtaining an accurate valuation is a significant 
challenge. Perhaps this suggests that the entire portfolio valuation proposal 
is quixotic in its goal of Absolute Valuation, and should be considered only as 
a rough guide at best?

David T.


> 
> If a developer wanted to expand the scope of the price download module to
> allow downloading "as of" prices for arbitrary historical dates, I think
> many of us would buy him a beer.  Alas, right now I fear that the currently
> active developers have too many other things on their plates.
> 
> David C
> 

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

Re: trial balance - how to find mismatch question

[David Carlson]

Adrien, I think that you summarized the problem with "nearest in time"
nicely.  Wm, no doubt, had tongue in cheek when he was assigning a high
value to future prices.  You clarify that reports are often run "as of"
historical dates (and often need to match accounting reports submitted to
government agencies) thus could be exposed to erroneous values assigned
after the "as of" date by the "nearest in time" criterion.

Your final note that ideally the prices would always be downloaded on the
date they are needed for the report is true, but as a practical matter it
is sometimes difficult to do, as the prices are often posted on the
internet several hours after the respective closing bell, and now that the
F:Q module is sometimes unable to acquire some prices on the first pass, it
is sometimes problematic whether it has even succeeded in getting all the
needed prices.  If it is done by a chron job, the job would need very
intelligent error handling capability to be confident about success.

If a developer wanted to expand the scope of the price download module to
allow downloading "as of" prices for arbitrary historical dates, I think
many of us would buy him a beer.  Alas, right now I fear that the currently
active developers have too many other things on their plates.

David C


On Mon, Mar 5, 2018 at 4:36 PM, Adrien Monteleone <
adrien.montele...@gmail.com> wrote:

> Wm,
>
> Consider the case of running a historical Balance Sheet for a date that
> falls on a market holiday that also falls on a weekend. The latest price
> prior to that holiday might be 2 days prior. The ’nearest price’ will be
> the day after the holiday. If Gnucash is pulling the day after price, it IS
> the ’nearest price’ to the target date of the report, but it is a ‘future
> price’ with respect to the report. Had you run the report on the actual day
> of the holiday, you’d get a different result. (the price from 2 days prior
> would be used)
>
> It isn’t that people are magically downloading prices from the future, but
> that the case of running a historical report might pull in a price that is
> closer to the report date, but actually in the future with respect to the
> report date that is the problem.
>
> If 2 days prior to the report, the market for silver closed at $16.50 and
> the day after the holiday, the market closed at $17.00 and GC used $17.00
> for the commodity price because it was only 1 day from the report date as
> opposed to 2 days, the report would overstate the assets by 3% as of the
> date of the report and be incorrect.
>
> Holidays alone aren’t the problem. It happens with respect to when you
> actually ‘get prices’. Perhaps the markets weren’t closed at all crossing a
> period boundary, and you routinely get prices on the first of the month.
> Running a Balance Sheet on any end of month day will always produce the
> wrong result. GC will use price on the day after the report, not the one
> before the report.
>
> What is needed here is a ‘latest price’ (as opposed to ‘most recent’ which
> is relative to the today’s date, not the report date) or else change/add an
> option for ’nearest in time prior’.
>
> In order to avoid this problem, one has to download on input prices for
> any specific day a report is run.
>
> Regards,
> Adrien
>
> > On Mar 5, 2018, at 4:08 PM, Wm via gnucash-devel <
> gnucash-devel@gnucash.org> wrote:
> >
> > On 03/03/2018 18:52, D via gnucash-devel wrote:
> >
> >> I think having nearest in time use future dates relative to the report
> date is not useful. Mind you, matching a broker statement for value (as
> opposed to holdings) is perhaps equally not useful.
> >> I guess I could see a point to a nearest in time using later dates (for
> example, when the date history is sparse, and the only earlier date is much
> earlier). But perhaps your suggestion of a separate setting would solve the
> dilemma.
> >
> > Where the heck do you get future prices from ?
> >
> > Seriously.  This is valuable information.  I want to know how you know.
> >
> > In any event, why aren't you telling gnc what it needs to know so it can
> multiply some numbers together?
> >
> > It is a *person* that says what a commodity was worth on a date not gnc
> after all.
> >
> > --
> > Wm
> >
> > never vote for a man that doesn't understand that imposing a tax on
> metal mauy work in the inverse to what he expects. duh
> >
> >
> > ___
> > 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: trial balance - how to find mismatch question

[Adrien Monteleone]

Wm,

Consider the case of running a historical Balance Sheet for a date that falls 
on a market holiday that also falls on a weekend. The latest price prior to 
that holiday might be 2 days prior. The ’nearest price’ will be the day after 
the holiday. If Gnucash is pulling the day after price, it IS the ’nearest 
price’ to the target date of the report, but it is a ‘future price’ with 
respect to the report. Had you run the report on the actual day of the holiday, 
you’d get a different result. (the price from 2 days prior would be used)

It isn’t that people are magically downloading prices from the future, but that 
the case of running a historical report might pull in a price that is closer to 
the report date, but actually in the future with respect to the report date 
that is the problem.

If 2 days prior to the report, the market for silver closed at $16.50 and the 
day after the holiday, the market closed at $17.00 and GC used $17.00 for the 
commodity price because it was only 1 day from the report date as opposed to 2 
days, the report would overstate the assets by 3% as of the date of the report 
and be incorrect.

Holidays alone aren’t the problem. It happens with respect to when you actually 
‘get prices’. Perhaps the markets weren’t closed at all crossing a period 
boundary, and you routinely get prices on the first of the month. Running a 
Balance Sheet on any end of month day will always produce the wrong result. GC 
will use price on the day after the report, not the one before the report.

What is needed here is a ‘latest price’ (as opposed to ‘most recent’ which is 
relative to the today’s date, not the report date) or else change/add an option 
for ’nearest in time prior’.

In order to avoid this problem, one has to download on input prices for any 
specific day a report is run.

Regards,
Adrien

> On Mar 5, 2018, at 4:08 PM, Wm via gnucash-devel  
> wrote:
> 
> On 03/03/2018 18:52, D via gnucash-devel wrote:
> 
>> I think having nearest in time use future dates relative to the report date 
>> is not useful. Mind you, matching a broker statement for value (as opposed 
>> to holdings) is perhaps equally not useful.
>> I guess I could see a point to a nearest in time using later dates (for 
>> example, when the date history is sparse, and the only earlier date is much 
>> earlier). But perhaps your suggestion of a separate setting would solve the 
>> dilemma.
> 
> Where the heck do you get future prices from ?
> 
> Seriously.  This is valuable information.  I want to know how you know.
> 
> In any event, why aren't you telling gnc what it needs to know so it can 
> multiply some numbers together?
> 
> It is a *person* that says what a commodity was worth on a date not gnc after 
> all.
> 
> -- 
> Wm
> 
> never vote for a man that doesn't understand that imposing a tax on metal 
> mauy work in the inverse to what he expects. duh
> 
> 
> ___
> 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: trial balance - how to find mismatch question

[Wm via gnucash-devel]

On 03/03/2018 18:52, D via gnucash-devel wrote:


I think having the extra option would be useful and less confusing than having
"Nearest in time" only look backwards.


Nearest in time is relative to the report date?  Where is the confusion?

--
Wm

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

Re: trial balance - how to find mismatch question

[Wm via gnucash-devel]

On 03/03/2018 18:52, D via gnucash-devel wrote:


I think having nearest in time use future dates relative to the report date is 
not useful. Mind you, matching a broker statement for value (as opposed to 
holdings) is perhaps equally not useful.

I guess I could see a point to a nearest in time using later dates (for 
example, when the date history is sparse, and the only earlier date is much 
earlier). But perhaps your suggestion of a separate setting would solve the 
dilemma.


Where the heck do you get future prices from ?

Seriously.  This is valuable information.  I want to know how you know.

In any event, why aren't you telling gnc what it needs to know so it can 
multiply some numbers together?


It is a *person* that says what a commodity was worth on a date not gnc 
after all.


--
Wm

never vote for a man that doesn't understand that imposing a tax on 
metal mauy work in the inverse to what he expects. duh



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

Re: trial balance - how to find mismatch question

[Wm via gnucash-devel]

On 03/03/2018 17:59, Geert Janssens wrote:

Op zaterdag 3 maart 2018 16:35:27 CET schreef David Carlson:

On January 30, 2015 I reported
https://bugzilla.gnome.org/show_bug.cgi?id=743753 pointing out this
behavior in Gnucash suggesting that the nearest in time criterion should
not select future dates.  That bug report applied to release 2.6.5 and as
of today it still has a status of "New"  If this criterion with it's
current behavior is the desired behavior, I assert that there should be
another criterion "last price on or before" so users can make their GnuCash
year end reports match their brokers statements without fudging prices in
their data files.




I think having the extra option would be useful and less confusing than having
"Nearest in time" only look backwards.

Geert


Ummm, Geert, he's talking about a conversation from 2015

The "Nearest in time" as a sensible price default happened *after* that.

Further, as far as I know, if I want a future price for any commodity I 
have to pay for it.


How can we, ordinary people, be getting these future prices in the first 
place?


Do other people not realise how much a future price can be worth?  We 
are talking millions of USD, GBP or EUR and that could be millions less 
or more than you currently have.


===

You're also being lazy wrt your tax reports and I reckon once you've 
done them you'll want "Nearest in time" to mean what it says and you'll 
realise you've been lazy setting your period dates (I do that too).

--
Wm



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

Re: trial balance - how to find mismatch question

[D via gnucash-devel]

Geert,

I think having nearest in time use future dates relative to the report date is 
not useful. Mind you, matching a broker statement for value (as opposed to 
holdings) is perhaps equally not useful.

I guess I could see a point to a nearest in time using later dates (for 
example, when the date history is sparse, and the only earlier date is much 
earlier). But perhaps your suggestion of a separate setting would solve the 
dilemma.

David

On March 3, 2018, at 11:00 PM, Geert Janssens  
wrote:

Op zaterdag 3 maart 2018 16:35:27 CET schreef David Carlson:
> On January 30, 2015 I reported
> https://bugzilla.gnome.org/show_bug.cgi?id=743753 pointing out this
> behavior in Gnucash suggesting that the nearest in time criterion should
> not select future dates.  That bug report applied to release 2.6.5 and as
> of today it still has a status of "New"  If this criterion with it's
> current behavior is the desired behavior, I assert that there should be
> another criterion "last price on or before" so users can make their GnuCash
> year end reports match their brokers statements without fudging prices in
> their data files.
I think having the extra option would be useful and less confusing than having 
"Nearest in time" only look backwards.

Geert


___
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: trial balance - how to find mismatch question

[Geert Janssens]

Op zaterdag 3 maart 2018 16:35:27 CET schreef David Carlson:
> On January 30, 2015 I reported
> https://bugzilla.gnome.org/show_bug.cgi?id=743753 pointing out this
> behavior in Gnucash suggesting that the nearest in time criterion should
> not select future dates.  That bug report applied to release 2.6.5 and as
> of today it still has a status of "New"  If this criterion with it's
> current behavior is the desired behavior, I assert that there should be
> another criterion "last price on or before" so users can make their GnuCash
> year end reports match their brokers statements without fudging prices in
> their data files.
I think having the extra option would be useful and less confusing than having 
"Nearest in time" only look backwards.

Geert


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

Re: trial balance - how to find mismatch question

[David Carlson]

I am not sure where Wm is going with his comments but I can state that I
just ran the Trial Balance report in GnuCash release 2.6.18, which is not
quite the very latest release available but is a known reference point.

I changed the report dates to start at the beginning of last year and end
at the end of last year, otherwise I left all other settings at their
default.  The Commodity Price Source defaulted to Nearest in Time.

It happens that there is 500 shares of AT (T) stock in this data file and
there are prices in the database for Friday December 29 2017 ($38.88) and
Tuesday January 2 2017 ($38.54).  Given those numbers, the Trial Balance
Report puts the value of those
 shares at $19,270.00.  My year-end brokerage statement put the price at
$38.88 for a value of $19,440.00.  I think that the report should match my
brokerage statement.

Now it happens that the discrepancy comes from the report's selection of
nearest in time as the price source, and the fact that GnuCash chose the
January 2 price rather than the December 29 price.

On January 30, 2015 I reported
https://bugzilla.gnome.org/show_bug.cgi?id=743753 pointing out this
behavior in Gnucash suggesting that the nearest in time criterion should
not select future dates.  That bug report applied to release 2.6.5 and as
of today it still has a status of "New"  If this criterion with it's
current behavior is the desired behavior, I assert that there should be
another criterion "last price on or before" so users can make their GnuCash
year end reports match their brokers statements without fudging prices in
their data files.

David C

On Sat, Mar 3, 2018 at 6:11 AM, Wm via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> On 16/02/2018 11:24, Christopher Lam wrote:
>
>> I like the way this is going. Please describe or file minimal data file
>> cases in Bugzilla. Perhaps I'll be able to decode the trial balance and we
>> can decide then what it should really do.
>>
>
> It is possible I've missed a detail but in RL a TB should only be for
> *one* currency or commodity or for many if they are each indicated.
>
> It is near impossible to reconcile a multi-variate TB because the
> underlying values are changing as you attempt it.
>
> The reconciliation of the separate bits can involve thinking but is the
> sensible approach.  You take a view about values either before the TB
> reconciliation or after, some governments have rules about this, etc.
>
> I don't know anyone that does a multivariate [1] TB and expects it to
> balance live [2].
>
> I pull the TB's for each class and give them to the people to reconcile,
> at the end we put them together. I suggest you try this approach.
>
> I'm surprised and mildly disappointed JohnR has found it necessary to
> contribute to this thread.  I think he has better things to do.
>
> [1] more than one commodity / currency / something that changes during a
> minute / hour / day / week / month.
>
> [2] not a joke, I don't think big banks do it and they are way ahead of
> little people like you or I.
>
> --
> Wm
>
> never vote for a man like Trump if you believe in honest accounting, he
> can't add up :)
>
>
>
> ___
> 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: trial balance - how to find mismatch question

[Wm via gnucash-devel]

On 16/02/2018 11:24, Christopher Lam wrote:

I like the way this is going. Please describe or file minimal data file
cases in Bugzilla. Perhaps I'll be able to decode the trial balance and we
can decide then what it should really do.


It is possible I've missed a detail but in RL a TB should only be for 
*one* currency or commodity or for many if they are each indicated.


It is near impossible to reconcile a multi-variate TB because the 
underlying values are changing as you attempt it.


The reconciliation of the separate bits can involve thinking but is the 
sensible approach.  You take a view about values either before the TB 
reconciliation or after, some governments have rules about this, etc.


I don't know anyone that does a multivariate [1] TB and expects it to 
balance live [2].


I pull the TB's for each class and give them to the people to reconcile, 
at the end we put them together. I suggest you try this approach.


I'm surprised and mildly disappointed JohnR has found it necessary to 
contribute to this thread.  I think he has better things to do.


[1] more than one commodity / currency / something that changes during a 
minute / hour / day / week / month.


[2] not a joke, I don't think big banks do it and they are way ahead of 
little people like you or I.


--
Wm

never vote for a man like Trump if you believe in honest accounting, he 
can't add up :)



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

Re: trial balance - how to find mismatch question

[Wm via gnucash-devel]

On 16/02/2018 10:57, David Carlson wrote:


As another user with a lot of stock trades, I sometimes use that report to
find an issue, although I have developed a process involving outside
spreadsheets to calculate realized gains per security account as GnuCash
calculates them and net gains as the IRS wants them, so I rarely need the
report now.  The last time that I used the report I found that when I had a
security account with not-so-simple combinations of lots being traded or
when I had an account involving reinvested dividends it was still
problematic whether I actually matched and resolved all the gains
correctly.  I deliberately avoided going down the Trading Accounts rabbit
hole at that time, but it may be worthwhile to give that a fresh look.


I know you may hate me but I find trading accounts essential to my 
understanding of the value of stuff I have.  I commend it to you, if 
only in a test book so you can realise how much of a dickhead Trump is 
with his USA vs Canada metal announcements today.



Today I am using Windows GnuCash release 2.6.18, and I found that the
report has changed since sometime in the early 2.6 series when I last used
it.  For all I know, it may be different again in release 2.6.19 and in
2.7/3.0 coming out soon.


Duh


Having given you my perspective, I did notice that the report currently
uses the 'nearest in time' estimate of the date to use when extracting
values from the currency and commodity tables.  That estimate is a poor
method to use in my opinion because that often points to a future date when
there is no value for the target date.


That is stupid.  There cannot be a "nearest in time" in the future 
unless someone enters it manually and no sensible person does that. Or 
did you enter a future date, perhaps ?


FFS, Carlson, stop saying stupid things in public!


This happens frequently when target
dates fall on weekends or holidays.


Please *STOP* saying things that aren't true!

>  It is possible that Adrien's residual

imbalance may be at least exacerbated by this point.


Nope, nearest in time is the most accurate way of arriving at the value 
of something.  Because gnc is not intended for trading a day or two 
before or after doesn't matter.



Also, I want to thank David T for noticing that in my earlier comments I
was referring to the unrealized gain imbalance value that this report
produces rather than the Imbalance accounts that get created when
individual transactions are incomplete as sometimes happens in transaction
imports.  That difference is critical to this discussion.  I did fail to
make that point clear then.

For completeness I should also mention that there are other parameters or
variables available to adjust in this report which may or may not result in
differences in the final values reported by a certain instance of the
report operating on a certain set of data.

There is an option section on adjusting entries and closing entries.  How
does the report identify these?  There are three report variations under
the general tab and there is a whole new section on merchandising that
could impact a report in an undesired way for users that accidentally
format some data incorrectly.  There is no help to let the user ascertain
how or if these things affect him.

I will stop here.


That is probably best as you clearly don't know what you are talking about.

Have you considered trying the user list instead?

--
Wm

never vote for someone that thinks arming teachers is a good response to 
ex-pupils shooting teachers and pupils ... unless you voted for the 
fuckwit in the first place in which case, hey, lets kill some more 
children in an interesting and unique NRA USA way.


The NRA *LOVES* dead kids, remember!

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

Re: trial balance - how to find mismatch question

[John Ralls]

> On Feb 16, 2018, at 12:20 AM, Adrien Monteleone  
> wrote:
> 
> At least on my version of the Trial Balance report, there is no ‘Imbalance 
> entry’ specifically.
> 
> There is at the bottom, the Imbalance-XXX and Orphan-XXX accounts listed 
> along with the others.
> 
> There is also a line for ‘Unrealized Gains’ or ‘Unrealized Losses’ (I have 
> the latter, even though the report duration was a single day with no price 
> changes, I gave up trying to figure that one out)
> 
> The ‘imbalance’ I’m speaking of trying to resolve, or at least finally 
> attributed to a rounding error with the XAG account, was simply the 
> difference between what the report shows as Total Debits & Total Credits. 
> (note, these aren’t labeled as such on the report - but they appear at the 
> bottom, and that’s clearly what they are) There is no figure on the report 
> that shows this difference. I had to calculate it manually. When I decided to 
> audit the report for each account is when I found the foreign currency 
> account out of whack. The remaining difference was attributable entirely to 
> the ‘unrealized losses’ line.
> 
> So, the full difference between debits and credi is the SUM of the 
> ‘Unrealized Gains/Losses’ line and the discrepancy due to rounding.
> 
> At least in my case.
> 
> So there are two problems with the report:
> 
> 1) There should be no losses or gains if there were no trading transactions. 
> Certainly, this is impossible if there is only one day on the range of the 
> report and the price is the same. If all you have are opening entries and you 
> attempt to run a trial balance for that same day, you can’t have either a 
> gain or a loss, unrealized or not.
> 
> 2) Because the Equity:Opening Balances account is the result of rounded 
> figures for each entry in a foreign currency, the report’s method of taking 
> the foreign currency ending balance as of a date and doing the exchange rate 
> calculation at the end, will always produce a discrepancy. The report would 
> have to sum the book-default currency amounts individually or somehow a 
> book-default currency balance would have to be maintained and that used 
> instead. Alternatively, a foreign currency account could use the same 
> precision as the foreign currency itself, thus removing the potential for 
> rounding errors if not eliminating them.
> 
> Possibly, increasing the decimal places and re-entering the transactions for 
> the XAG account might resolve the rounding issue. (only because now the USD 
> amounts sum correctly to match since they don’t round enough) But then ALL 
> USD accounts would have this extra precision which is not desirable generally.
> 
> The alternative would be to reduce the precision of the XAG account, but 
> again, that is undesirable for accurate tracking of ownership quantities of 
> the actual metal. (or currency if that’s the case)
> 
> The per-account precision setting seems to only affect the default currency 
> for that account, in this case, XAG, not USD, which seems only to be 
> controlled by the book setting.

Adriene,

Pay close attention to the price source on the Trial Balance report. The 
default value of “Nearest in Time” can produce anomalous results. Try “Average 
Cost”, but be mindful of https://bugzilla.gnome.org/show_bug.cgi?id=775368 
.

The default precision (“smallest commodity unit” or SCU) for an account *is* 
the value for the commodity/currency in which it’s denominated. For most 
currencies that’s 1/100. Prices aren’t rounded by GnuCash, but the prices you 
get from Finance::Quote are, so if you have trades from before 2.6.12 (when 
GnuCash started entering calculated prices into the pricedb) or have replaced 
calculated prices with market prices then you’ll get a rounding error.

Regards,
John Ralls

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

Re: trial balance - how to find mismatch question

[Christopher Lam]

quot; <
> > >>> adrien.montele...@gmail.com> wrote:
> > >>>> I just noticed the subject was wrong due to a user-digest error,
> > >>> re-applying the original.
> > >>>>
> > >>>> ———
> > >>>>
> > >>>> I’m having a bit of issue understanding the point of the
> trial-balance
> > >>> report in modern times. (I generally don’t use it as I mentioned)
> > >>>>
> > >>>> If each transaction self-balances, that is, debits = credits, how is
> > it
> > >>> possible to add up the debits individually and the credits
> > individually and
> > >>> not get a result that still balances? You can’t add up 1+2+3 = 5 and
> > 1+2+3
> > >>> = 6. It’s a mathematical impossibility.
> > >>>>
> > >>>> In addition, if you enter a transaction that doesn’t balance,
> Gnucash
> > >>> forces it to balance by using either the imbalance or orphan
> accounts.
> > So
> > >>> at least you’re alerted to amounts you need to fix, but technically,
> > debits
> > >>> still equal credits.
> > >>>>
> > >>>> Let’s assume I entered a transaction backwards and debited my cash
> > >>> account instead of crediting it, and credited an expense account
> > instead of
> > >>> debiting it. This should not affect the trial-balance. Sure, the
> > amounts
> > >>> are wrong for each account, but they still balance. Debits still
> equal
> > >>> credits.
> > >>>>
> > >>>> If I transpose two digits (the divisible by ‘9’ trick) then as long
> as
> > >>> my individual transaction I did this in balances, it still shouldn’t
> > show
> > >>> up as an imbalance on the trial-balance report. The other side would
> > ALSO
> > >>> have to be transposed or incorrect to match it. Gnucash won’t save
> the
> > >>> transaction unless it’s balanced.
> > >>>>
> > >>>> I can’t see what possible error could produce individually balanced
> > >>> transactions (required by Gnucash) and yet still have a trial-balance
> > where
> > >>> the debits do not equal credits AND both the imbalance account and
> > orphan
> > >>> accounts are empty.
> > >>>>
> > >>>> (note, I understand why this report is run with paper records
> because
> > >>> you’re copying stuff all over the place and might do so incorrectly.
> > But
> > >>> this isn’t the case with Gnucash)
> > >>>>
> > >>>> Regards,
> > >>>> Adrien
> > >>>>
> > >>>>> On Feb 15, 2018, at 5:06 PM, Adrien Monteleone <
> > >>> adrien.montele...@gmail.com> wrote:
> > >>>>>
> > >>>>> The 1899 date seems to make me think that has something to do with
> a
> > >>> setting in your OS concerning how to interpret 2-year dates. (I don’t
> > think
> > >>> Gnucash has this option, it might be hard coded)
> > >>>>>
> > >>>>> Try running the report again and make sure to enter the full
> 4-digit
> > >>> date and not just ’16’. Also, test with 12/30/2016 and 01/01/2017 and
> > see
> > >>> if it does the same thing or only on exactly 12/31/2016. You might
> have
> > >>> some corrupt data. That might even be the source date of the
> imbalance.
> > >>>>>
> > >>>>> I just entered those two dates in the same report and it worked
> fine,
> > >>> so this wouldn’t be a generic bug to the app, though it might be a
> bug
> > for
> > >>> a certain platform. (I’m on macOS 10.13 at the moment)
> > >>>>>
> > >>>>> Since you’ve narrowed down to a few weeks, I’d just take a look at
> > the
> > >>> General Ledger which contains all transactions from all accounts.
> > Click on
> > >>> View > Filter By… and set your date range. (maybe even a day before
> and
> > >>> after just to be thorough) Also be sure to check all boxes on the
> > Status
> > >>> tab in the Filter options. You want to see all transactions for that
> > date
> > >>> range. Then just look over them and see if anything looks out of
> > place. In
> > >>> pa

Re: trial balance - how to find mismatch question

[David T. via gnucash-devel]

bited my cash
> >>> account instead of crediting it, and credited an expense account
> instead of
> >>> debiting it. This should not affect the trial-balance. Sure, the
> amounts
> >>> are wrong for each account, but they still balance. Debits still equal
> >>> credits.
> >>>>
> >>>> If I transpose two digits (the divisible by ‘9’ trick) then as long as
> >>> my individual transaction I did this in balances, it still shouldn’t
> show
> >>> up as an imbalance on the trial-balance report. The other side would
> ALSO
> >>> have to be transposed or incorrect to match it. Gnucash won’t save the
> >>> transaction unless it’s balanced.
> >>>>
> >>>> I can’t see what possible error could produce individually balanced
> >>> transactions (required by Gnucash) and yet still have a trial-balance
> where
> >>> the debits do not equal credits AND both the imbalance account and
> orphan
> >>> accounts are empty.
> >>>>
> >>>> (note, I understand why this report is run with paper records because
> >>> you’re copying stuff all over the place and might do so incorrectly.
> But
> >>> this isn’t the case with Gnucash)
> >>>>
> >>>> Regards,
> >>>> Adrien
> >>>>
> >>>>> On Feb 15, 2018, at 5:06 PM, Adrien Monteleone <
> >>> adrien.montele...@gmail.com> wrote:
> >>>>>
> >>>>> The 1899 date seems to make me think that has something to do with a
> >>> setting in your OS concerning how to interpret 2-year dates. (I don’t
> think
> >>> Gnucash has this option, it might be hard coded)
> >>>>>
> >>>>> Try running the report again and make sure to enter the full 4-digit
> >>> date and not just ’16’. Also, test with 12/30/2016 and 01/01/2017 and
> see
> >>> if it does the same thing or only on exactly 12/31/2016. You might have
> >>> some corrupt data. That might even be the source date of the imbalance.
> >>>>>
> >>>>> I just entered those two dates in the same report and it worked fine,
> >>> so this wouldn’t be a generic bug to the app, though it might be a bug
> for
> >>> a certain platform. (I’m on macOS 10.13 at the moment)
> >>>>>
> >>>>> Since you’ve narrowed down to a few weeks, I’d just take a look at
> the
> >>> General Ledger which contains all transactions from all accounts.
> Click on
> >>> View > Filter By… and set your date range. (maybe even a day before and
> >>> after just to be thorough) Also be sure to check all boxes on the
> Status
> >>> tab in the Filter options. You want to see all transactions for that
> date
> >>> range. Then just look over them and see if anything looks out of
> place. In
> >>> particular, look for either the amount you are out of balance by or
> half
> >>> that amount if the variance is an even number. (meaning you have an
> entry
> >>> that is entered in reverse debit/credit, or entirely duplicated)
> >>>>>
> >>>>> For myself, I think I want to tackle one other area first. I recall
> >>> doing some re-organization and I went through a series of unposting
> paid
> >>> invoices and reposting them, causing my lot assignments to get out of
> >>> whack. I know I have some open lots that shouldn’t be there and many
> that
> >>> are applied to the wrong documents. I’ll clean that up first, then
> re-run
> >>> the trial balance and see if that does the trick. I’m not sure where
> the
> >>> Trial-Balance report is pulling its numbers from, but it won’t hurt to
> >>> perform that cleanup anyway.
> >>>>>
> >>>>> Regards,
> >>>>> Adrien
> >>>>>
> >>>>>> On Feb 15, 2018, at 2:35 PM, Elmar <etsc...@gmail.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 02/15/2018 02:28 PM, gnucash-user-requ...@gnucash.org wrote:
> >>>>>>> 
> >>> --
> >>>>>>>
> >>>>>>> Message: 1
> >>>>>>> Date: Thu, 15 Feb 2018 13:27:17 -0600
> >>>>>>> From: Adrien Monteleone <adrien.montele...@gmail.com>
> >>>&

Re: trial balance - how to find mismatch question

[David Carlson]

 up as an imbalance on the trial-balance report. The other side would
> ALSO
> >>> have to be transposed or incorrect to match it. Gnucash won’t save the
> >>> transaction unless it’s balanced.
> >>>>
> >>>> I can’t see what possible error could produce individually balanced
> >>> transactions (required by Gnucash) and yet still have a trial-balance
> where
> >>> the debits do not equal credits AND both the imbalance account and
> orphan
> >>> accounts are empty.
> >>>>
> >>>> (note, I understand why this report is run with paper records because
> >>> you’re copying stuff all over the place and might do so incorrectly.
> But
> >>> this isn’t the case with Gnucash)
> >>>>
> >>>> Regards,
> >>>> Adrien
> >>>>
> >>>>> On Feb 15, 2018, at 5:06 PM, Adrien Monteleone <
> >>> adrien.montele...@gmail.com> wrote:
> >>>>>
> >>>>> The 1899 date seems to make me think that has something to do with a
> >>> setting in your OS concerning how to interpret 2-year dates. (I don’t
> think
> >>> Gnucash has this option, it might be hard coded)
> >>>>>
> >>>>> Try running the report again and make sure to enter the full 4-digit
> >>> date and not just ’16’. Also, test with 12/30/2016 and 01/01/2017 and
> see
> >>> if it does the same thing or only on exactly 12/31/2016. You might have
> >>> some corrupt data. That might even be the source date of the imbalance.
> >>>>>
> >>>>> I just entered those two dates in the same report and it worked fine,
> >>> so this wouldn’t be a generic bug to the app, though it might be a bug
> for
> >>> a certain platform. (I’m on macOS 10.13 at the moment)
> >>>>>
> >>>>> Since you’ve narrowed down to a few weeks, I’d just take a look at
> the
> >>> General Ledger which contains all transactions from all accounts.
> Click on
> >>> View > Filter By… and set your date range. (maybe even a day before and
> >>> after just to be thorough) Also be sure to check all boxes on the
> Status
> >>> tab in the Filter options. You want to see all transactions for that
> date
> >>> range. Then just look over them and see if anything looks out of
> place. In
> >>> particular, look for either the amount you are out of balance by or
> half
> >>> that amount if the variance is an even number. (meaning you have an
> entry
> >>> that is entered in reverse debit/credit, or entirely duplicated)
> >>>>>
> >>>>> For myself, I think I want to tackle one other area first. I recall
> >>> doing some re-organization and I went through a series of unposting
> paid
> >>> invoices and reposting them, causing my lot assignments to get out of
> >>> whack. I know I have some open lots that shouldn’t be there and many
> that
> >>> are applied to the wrong documents. I’ll clean that up first, then
> re-run
> >>> the trial balance and see if that does the trick. I’m not sure where
> the
> >>> Trial-Balance report is pulling its numbers from, but it won’t hurt to
> >>> perform that cleanup anyway.
> >>>>>
> >>>>> Regards,
> >>>>> Adrien
> >>>>>
> >>>>>> On Feb 15, 2018, at 2:35 PM, Elmar <etsc...@gmail.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 02/15/2018 02:28 PM, gnucash-user-requ...@gnucash.org wrote:
> >>>>>>> 
> >>> --
> >>>>>>>
> >>>>>>> Message: 1
> >>>>>>> Date: Thu, 15 Feb 2018 13:27:17 -0600
> >>>>>>> From: Adrien Monteleone <adrien.montele...@gmail.com>
> >>>>>>> To: "gnucash-u...@gnucash.org" <gnucash-u...@gnucash.org>
> >>>>>>> Subject: Re: trial balance - how to find mismatch question
> >>>>>>> Message-ID: <823da1a8-b449-470f-ab10-e66505686...@gmail.com>
> >>>>>>> Content-Type: text/plain;   charset=utf-8
> >>>>>>> ...
> >>>>>>>
> >>>>>>> Elmar,
> >>>>>>>
> >>>>>>> Reduce your end

Re: trial balance - how to find mismatch question

[Adrien Monteleone]

;>> I just noticed the subject was wrong due to a user-digest error,
>>> re-applying the original.
>>>> 
>>>> ———
>>>> 
>>>> I’m having a bit of issue understanding the point of the trial-balance
>>> report in modern times. (I generally don’t use it as I mentioned)
>>>> 
>>>> If each transaction self-balances, that is, debits = credits, how is it
>>> possible to add up the debits individually and the credits individually and
>>> not get a result that still balances? You can’t add up 1+2+3 = 5 and 1+2+3
>>> = 6. It’s a mathematical impossibility.
>>>> 
>>>> In addition, if you enter a transaction that doesn’t balance, Gnucash
>>> forces it to balance by using either the imbalance or orphan accounts. So
>>> at least you’re alerted to amounts you need to fix, but technically, debits
>>> still equal credits.
>>>> 
>>>> Let’s assume I entered a transaction backwards and debited my cash
>>> account instead of crediting it, and credited an expense account instead of
>>> debiting it. This should not affect the trial-balance. Sure, the amounts
>>> are wrong for each account, but they still balance. Debits still equal
>>> credits.
>>>> 
>>>> If I transpose two digits (the divisible by ‘9’ trick) then as long as
>>> my individual transaction I did this in balances, it still shouldn’t show
>>> up as an imbalance on the trial-balance report. The other side would ALSO
>>> have to be transposed or incorrect to match it. Gnucash won’t save the
>>> transaction unless it’s balanced.
>>>> 
>>>> I can’t see what possible error could produce individually balanced
>>> transactions (required by Gnucash) and yet still have a trial-balance where
>>> the debits do not equal credits AND both the imbalance account and orphan
>>> accounts are empty.
>>>> 
>>>> (note, I understand why this report is run with paper records because
>>> you’re copying stuff all over the place and might do so incorrectly. But
>>> this isn’t the case with Gnucash)
>>>> 
>>>> Regards,
>>>> Adrien
>>>> 
>>>>> On Feb 15, 2018, at 5:06 PM, Adrien Monteleone <
>>> adrien.montele...@gmail.com> wrote:
>>>>> 
>>>>> The 1899 date seems to make me think that has something to do with a
>>> setting in your OS concerning how to interpret 2-year dates. (I don’t think
>>> Gnucash has this option, it might be hard coded)
>>>>> 
>>>>> Try running the report again and make sure to enter the full 4-digit
>>> date and not just ’16’. Also, test with 12/30/2016 and 01/01/2017 and see
>>> if it does the same thing or only on exactly 12/31/2016. You might have
>>> some corrupt data. That might even be the source date of the imbalance.
>>>>> 
>>>>> I just entered those two dates in the same report and it worked fine,
>>> so this wouldn’t be a generic bug to the app, though it might be a bug for
>>> a certain platform. (I’m on macOS 10.13 at the moment)
>>>>> 
>>>>> Since you’ve narrowed down to a few weeks, I’d just take a look at the
>>> General Ledger which contains all transactions from all accounts. Click on
>>> View > Filter By… and set your date range. (maybe even a day before and
>>> after just to be thorough) Also be sure to check all boxes on the Status
>>> tab in the Filter options. You want to see all transactions for that date
>>> range. Then just look over them and see if anything looks out of place. In
>>> particular, look for either the amount you are out of balance by or half
>>> that amount if the variance is an even number. (meaning you have an entry
>>> that is entered in reverse debit/credit, or entirely duplicated)
>>>>> 
>>>>> For myself, I think I want to tackle one other area first. I recall
>>> doing some re-organization and I went through a series of unposting paid
>>> invoices and reposting them, causing my lot assignments to get out of
>>> whack. I know I have some open lots that shouldn’t be there and many that
>>> are applied to the wrong documents. I’ll clean that up first, then re-run
>>> the trial balance and see if that does the trick. I’m not sure where the
>>> Trial-Balance report is pulling its numbers from, but it won’t hurt to
>>> perform that cleanup anyway.
>>>>> 
>>>>> Regards,
>>>>> Adrien

Re: trial balance - how to find mismatch question

[David T. via gnucash-devel]

n macOS 10.13 at the moment)
>>>> 
>>>> Since you’ve narrowed down to a few weeks, I’d just take a look at the
>> General Ledger which contains all transactions from all accounts. Click on
>> View > Filter By… and set your date range. (maybe even a day before and
>> after just to be thorough) Also be sure to check all boxes on the Status
>> tab in the Filter options. You want to see all transactions for that date
>> range. Then just look over them and see if anything looks out of place. In
>> particular, look for either the amount you are out of balance by or half
>> that amount if the variance is an even number. (meaning you have an entry
>> that is entered in reverse debit/credit, or entirely duplicated)
>>>> 
>>>> For myself, I think I want to tackle one other area first. I recall
>> doing some re-organization and I went through a series of unposting paid
>> invoices and reposting them, causing my lot assignments to get out of
>> whack. I know I have some open lots that shouldn’t be there and many that
>> are applied to the wrong documents. I’ll clean that up first, then re-run
>> the trial balance and see if that does the trick. I’m not sure where the
>> Trial-Balance report is pulling its numbers from, but it won’t hurt to
>> perform that cleanup anyway.
>>>> 
>>>> Regards,
>>>> Adrien
>>>> 
>>>>> On Feb 15, 2018, at 2:35 PM, Elmar <etsc...@gmail.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 02/15/2018 02:28 PM, gnucash-user-requ...@gnucash.org wrote:
>>>>>> 
>> --
>>>>>> 
>>>>>> Message: 1
>>>>>> Date: Thu, 15 Feb 2018 13:27:17 -0600
>>>>>> From: Adrien Monteleone <adrien.montele...@gmail.com>
>>>>>> To: "gnucash-u...@gnucash.org" <gnucash-u...@gnucash.org>
>>>>>> Subject: Re: trial balance - how to find mismatch question
>>>>>> Message-ID: <823da1a8-b449-470f-ab10-e66505686...@gmail.com>
>>>>>> Content-Type: text/plain;   charset=utf-8
>>>>>> ...
>>>>>> 
>>>>>> Elmar,
>>>>>> 
>>>>>> Reduce your ending date so the range is half of what it was. Re-run
>> the report. Is it s[t]ill out of balance? Keep doing this till you get a
>> balance, then set that ending date to a new start date, and start working
>> forwards till you get out of balance again. This will help you narrow down
>> where on the calendar the error occurred.
>>>>>> 
>>>>>> Regards,
>>>>>> Adrien
>>>>> OK - did that and ran into something VERY strange.  Everything stayed
>> in balance up to 07/12/2016.  Setting that as the start date and 12/31/2016
>> as the end date, as soon as I hit "apply", QC overwrites the end date with
>> - get this - 02/27/1899 !!!  This of course produces nonsense.  One day
>> later (01/01/2017) works fine and shows the imbalance.  So, have I 1) found
>> a bug, and 2) given I have narrowed the date range to a few weeks, what
>> report should I run to find the weirdness? - Elmar
>>>>> ___
>>>>> gnucash-user mailing list
>>>>> gnucash-u...@gnucash.org
>>>>> To update your subscription preferences or to unsubscribe:
>>>>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>>>> If you are using Nabble or Gmane, please see
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>>>>> -
>>>>> Please remember to CC this list on all your replies.
>>>>> You can do this by using Reply-To-List or Reply-All.
>>>> 
>>> 
>>> ___
>>> gnucash-user mailing list
>>> gnucash-u...@gnucash.org
>>> To update your subscription preferences or to unsubscribe:
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>> If you are using Nabble or Gmane, please see
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>>> -
>>> Please remember to CC this list on all your replies.
>>> You can do this by using Reply-To-List or Reply-All.
>> 
>> ___
>> gnucash-user mailing list
>> gnucash-u...@gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> If you are using Nabble or Gmane, please see
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> -
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
> ___
> 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: trial balance - how to find mismatch question

[Christopher Lam]

t; Trial-Balance report is pulling its numbers from, but it won’t hurt to
> perform that cleanup anyway.
> > >
> > > Regards,
> > > Adrien
> > >
> > >> On Feb 15, 2018, at 2:35 PM, Elmar <etsc...@gmail.com> wrote:
> > >>
> > >>
> > >>
> > >> On 02/15/2018 02:28 PM, gnucash-user-requ...@gnucash.org wrote:
> > >>> 
> --
> > >>>
> > >>> Message: 1
> > >>> Date: Thu, 15 Feb 2018 13:27:17 -0600
> > >>> From: Adrien Monteleone <adrien.montele...@gmail.com>
> > >>> To: "gnucash-u...@gnucash.org" <gnucash-u...@gnucash.org>
> > >>> Subject: Re: trial balance - how to find mismatch question
> > >>> Message-ID: <823da1a8-b449-470f-ab10-e66505686...@gmail.com>
> > >>> Content-Type: text/plain;   charset=utf-8
> > >>> ...
> > >>>
> > >>> Elmar,
> > >>>
> > >>> Reduce your ending date so the range is half of what it was. Re-run
> the report. Is it s[t]ill out of balance? Keep doing this till you get a
> balance, then set that ending date to a new start date, and start working
> forwards till you get out of balance again. This will help you narrow down
> where on the calendar the error occurred.
> > >>>
> > >>> Regards,
> > >>> Adrien
> > >> OK - did that and ran into something VERY strange.  Everything stayed
> in balance up to 07/12/2016.  Setting that as the start date and 12/31/2016
> as the end date, as soon as I hit "apply", QC overwrites the end date with
> - get this - 02/27/1899 !!!  This of course produces nonsense.  One day
> later (01/01/2017) works fine and shows the imbalance.  So, have I 1) found
> a bug, and 2) given I have narrowed the date range to a few weeks, what
> report should I run to find the weirdness? - Elmar
> > >> ___
> > >> gnucash-user mailing list
> > >> gnucash-u...@gnucash.org
> > >> To update your subscription preferences or to unsubscribe:
> > >> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > >> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> > >> -
> > >> Please remember to CC this list on all your replies.
> > >> You can do this by using Reply-To-List or Reply-All.
> > >
> >
> > ___
> > gnucash-user mailing list
> > gnucash-u...@gnucash.org
> > To update your subscription preferences or to unsubscribe:
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> > -
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
> ___
> gnucash-user mailing list
> gnucash-u...@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see
> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel