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
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
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
> On Mar 3, 2018, at 12:37 AM, Martin Preuss wrote:
>
> Hi,
>
> Am 03.03.2018 um 05:40 schrieb John Ralls:
> [...]
>> https://fedora.pkgs.org/27/fedora-x86_64/ktoblzcheck-1.44-9.fc27.x86_64.rpm.html
>>
>>
On 16/02/2018 04:07, David T. via gnucash-devel wrote:
Hello,
In my quixotic quest to try and get quote retrieval working again on my Mac,
I’ve been looking at ways to remove and reload all the Perl underlying
Finance::Quote. (As John noted to me recently, there isn’t any uninstall
command
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
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