<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>John,</p>
<p>Thank you. I'll try to remember to include commit urls in
future correspondence. </p>
<p>Regarding the "Refactor" commit, consistency does have it's
benefits. If you do decide to improve the flow in
gnc:get-exchange-cost-totals, a similar change would also apply
to gnc:get-exchange-totals.</p>
<p>Regards,</p>
<p>Sherlock</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 8/25/25 1:38 PM, John Ralls wrote:<br>
</div>
<blockquote type="cite"
cite="mid:C8BC3B0A-6B67-43CC-A349-845F0D95FC8E@ceridwen.us">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>I suppose your October 2008 claim comes from <a
href="https://github.com/Gnucash/gnucash/commit/425ec8eb68254948cb03b2c152ebab05b20acb0e"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/Gnucash/gnucash/commit/425ec8eb68254948cb03b2c152ebab05b20acb0e</a> that
negates shares and value if they’re reversed in the pair because
the commodity isn’t the transaction currency. </div>
<div><br>
</div>
<div>That remained essentially unchanged until <a
href="https://github.com/Gnucash/gnucash/commit/ce675eaac6b52e85cd9fe8602002f7b9d55e63ba"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/Gnucash/gnucash/commit/ce675eaac6b52e85cd9fe8602002f7b9d55e63ba</a>
on 3 May 2019 substantially reordered the function and
introduced the clause that you propose to change. That would be
“the culprit” I asked you for yesterday morning. That commit is
titled “Refactor” but it would be more correct to call it
“Complicate”. It turns two conditional branches—split commodity
is or isn’t the transaction currency—into 5. I agree with you
that the amounts in the last case should be negated: The
commodity isn’t the transaction currency. What I’m less sure
about is that it needs to be a separate case at all—or rather
that the `(assoc acc-comm sublist)` test needs to exist.
Changing that to a plain `else` and deleting the current `else`
clause should accomplish the same thing and removes the logic
change buried in what’s claimed to be a refactor.</div>
<div><br>
</div>
<div>Regards,</div>
<div>John Ralls</div>
<div><br>
</div>
<div><br>
</div>
<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On Aug 24, 2025, at 13:20, Sherlock Holmes
<a class="moz-txt-link-rfc2396E" href="mailto:sh025622@gmail.com"><sh025622@gmail.com></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<div>
<p>John,</p>
<p>Yes. I have. And I do think I understand both
algorithms and their evolution.</p>
<p>Again, assuming the sign swap was necessary for
"average cost", when the sign swap was first effectuated
17 years ago, it does not appear to have been applied on
the first entry. This code has been rewritten multiple
times since then and the issue appears to have been
replicated time after time. I know it seems unlikely
but have a look at the code. What am I missing?</p>
<p>Regards,</p>
<p>Sherlock</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 8/24/25 12:43 PM, John
Ralls wrote:<br>
</div>
<blockquote type="cite"
cite="mid:BEAFCD0F-6F95-4646-9463-826513254C3B@ceridwen.us">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
Sherlock,
<div><br>
</div>
<div>Seems unlikely. Have you read through <a
href="https://bugs.gnucash.org/show_bug.cgi?id=797796"
moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.gnucash.org/show_bug.cgi?id=797796</a>, <a
href="https://bugs.gnucash.org/show_bug.cgi?id=775368"
moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.gnucash.org/show_bug.cgi?id=775368</a>,
and <a
href="https://bugs.gnucash.org/show_bug.cgi?id=775368"
moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.gnucash.org/show_bug.cgi?id=775368</a> (the
latter two are referenced in <a
href="https://bugs.gnucash.org/show_bug.cgi?id=797796#c8"
moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.gnucash.org/show_bug.cgi?id=797796#c8</a>)
so that you thoroughly understand the problem and the
design of the algorithm?</div>
<div><br>
</div>
<div>Regards,</div>
<div>John Ralls</div>
<div><br>
</div>
<div>
<div><br>
<blockquote type="cite">
<div>On Aug 24, 2025, at 12:13, Sherlock Holmes <a
class="moz-txt-link-rfc2396E"
href="mailto:sh025622@gmail.com"
moz-do-not-send="true"><sh025622@gmail.com></a>
wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<div>
<p>John,</p>
<p>Here's where I'm at: I suspect the
initial "account" commodity list entry in
the "average cost" algorithm has been a bit
off since Oct 16, 2008. It appears the
share and value signs are supposed to be
swapped on assignment to the "account"
commodity list, but are not when the list is
first created. See the attached patch file.</p>
<p>Thoughts?</p>
<p>Regards,</p>
<p>Sherlock</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 8/24/25 10:21
AM, Sherlock Holmes wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3a69f004-d010-4be8-9947-f36529fbec16@gmail.com">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<p>John,</p>
<p>I'm still working it. It appears to me
that both algorithms may have gone a bit
awry sometime ago although the "average
price" may be okay. Specifically, the
initial comm-list entry became an else
case which meant it needed to perform the
assignments and, in the "average cost",
the sign handling doesn't </p>
<p>My WAG was just that. Just a quick check
to see if I was in the right area. </p>
<p><br>
</p>
<p>Regards,</p>
<p>Sherlock </p>
<div> <br class="webkit-block-placeholder">
</div>
<div class="moz-cite-prefix">On 8/24/25 9:16
AM, John Ralls wrote:<br>
</div>
<blockquote type="cite"
cite="mid:F631D996-F789-4651-AC34-A2CFB83EEF7A@ceridwen.us">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<div> Sherlock,</div>
<div><br>
</div>
What’s this part for? It seems irrelevant
to Chang Wang’s example as that doesn’t
use trading accounts:
<div>
<div>-</div>
<div>- ;; However skip splits in
trading accounts as these
counterbalance</div>
<div>- ;; the actual value and
share amounts back to zero</div>
<div>- ((eqv? (xaccAccountGetType
(xaccSplitGetAccount (car
comm-splits)))</div>
<div>- ACCT-TYPE-TRADING)</div>
<div>- (loop (cdr comm-splits)</div>
<div>- sumlist))</div>
<div> </div>
<div>I guess you did a bisect to arrive
at the 2019 change date. There were 8
changes to gnc-commodity-utils.scm
that day. Which one was the culprit?</div>
<div><br>
</div>
<div>Regards,</div>
<div>John Ralls</div>
<div><br>
</div>
<div><br>
<blockquote type="cite">
<div>On Aug 23, 2025, at 20:18,
Sherlock Holmes <a
class="moz-txt-link-rfc2396E"
href="mailto:sh025622@gmail.com"
moz-do-not-send="true"><sh025622@gmail.com></a>
wrote:</div>
<br
class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<div>
<p>I concur.</p>
<p>There are significant
differences in the
implementation between
gnc:get-exchange-totals and
gnc:get-exchange-cost-totals
that I believe are the root
cause of the issue. These
differences appear to date
back to May 3, 2019. As a
WAG, I modified
gnc:get-exchange-cost-totals
to match
gnc:get-exchange-totals in the
attached patch and the issue
you've raised appears to be
resolved. I have not done any
further testing,</p>
<p>Regards,</p>
<p>Sherlock</p>
<p><br>
</p>
<div class="moz-cite-prefix">On
8/23/25 2:20 PM, Chang Wang
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGyuYwAVUyknUp=af6_31Ga8+qPh5g7xjREV+NK6iy5tmn_wYw@mail.gmail.com">
<meta
http-equiv="content-type"
content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Thanks for the
reminder. I'll post to the
user list in the future.</div>
<div>However, in the above
example, there is no gain
or loss due to currency
exchange as the exchange
rates are set to 1 so no
currency gain/loss needs
to be booked. And the
price source is set to
be Last up through report
date instead of average
cost. Therefore, I think
these are different
issues.</div>
</div>
<br>
<div
class="gmail_quote gmail_quote_container">
<div dir="ltr"
class="gmail_attr">On Sat,
Aug 23, 2025 at 3:51 PM
John Ralls <<a
href="mailto:jralls@ceridwen.us" moz-do-not-send="true"
class="moz-txt-link-freetext">jralls@ceridwen.us</a>> wrote:<br>
</div>
<blockquote
class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Oddly
I just told somebody on
IRC the same answer: <a
href="https://bugs.gnucash.org/show_bug.cgi?id=797796" rel="noreferrer"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://bugs.gnucash.org/show_bug.cgi?id=797796</a><br>
<br>
Unless you’re willing to
submit a PR, this is a
user-list topic, so in the
future please use
gnucash-user instead of
gnucash-devel.<br>
<br>
Regards,<br>
John Ralls<br>
<br>
> On Aug 23, 2025, at
1:43 PM, Chang Wang <<a
href="mailto:wangchang327@gmail.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">wangchang327@gmail.com</a>> wrote:<br>
> <br>
> Hi all,<br>
> I noticed an issue
with the Trial Balance
report when using stock
trading and multiple
currencies. Even when
transactions are balanced,
the Trial Balance report
appears to break due to
incorrect calculation of
unrealized gains.<br>
> <br>
> I've attached an
uncompressed minimal
example to illustrate the
problem.<br>
> <br>
> Steps to reproduce:<br>
> Open the attached
book.<br>
> Generate a Trial
Balance report with
reporting currency set to
USD, price source set to
Last up through report
date, and enable Show
Foreign Currencies and
Exchange Rates.<br>
> <br>
> Observed behavior:<br>
> The report shows an
Unrealized Gain of
$20,800, which is
incorrect.<br>
> <br>
> Expected behavior:<br>
> The Unrealized Gain
should be $200.<br>
> <br>
> Explanation:<br>
> The example contains
three transactions:<br>
> 1) 08/02/2025 - Buy
one stock for 10,200 JPY.<br>
> 2) 08/03/2025 -
Exchange 100,000 JPY for
100,000 USD.<br>
> 3) 08/04/2025 - Buy
one stock for 10,400 JPY.<br>
> <br>
> The JPY/USD rate is
fixed at 1 on all days, so
there should be no
realized or unrealized
currency gains. Stock
prices are set at 10X00
JPY on 08/0X/2025, where X
= 1, 2, 3, 4.<br>
> <br>
> Therefore, in USD
reporting currency, the
Trial Balance should show
unrealized gains as:<br>
> (10,400 * 2) - 10,200
- 10,400 = 200 JPY = 200
USD<br>
> <br>
> Notably, the Balance
Sheet report does display
the correct unrealized
gain. And if transaction
3) or transaction 2) is
removed, the Trial Balance
turns out to be correct.<br>
> <br>
> I'm not familiar with
Scheme, so I wasn't able
to locate the problem in
the source code. I also
wasn't able to file a bug
on Bugzilla, since the
registration function
appears to be broken.<br>
> <br>
> Thanks for your
attention,<br>
> Chang<br>
>
<tb.gnucash>_______________________________________________</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</blockquote>
</div>
<span
id="cid:654B967E-1840-4CF0-8579-E94E711E68B9"><commodity-utilities.scm.patch></span></div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>