Lets all step back a second and consider what the report is supposed to show before deciding whether it is always correct.
The report is supposed to cover all of the assets and liabilities that were selected when configured only over time interval which was also selected during the configuration. It is supposed to use a method of valuation for accounts not in the base currency which is also selected during the report configuration. Over the last several years there have been a number of discussions about whether the various valuation methods work correctly, with respect to report dates vs dates available in the data file and even whether the values should be displayed or calculated with exact i.e. fractional numbers or in floating point. All of that is in the infrastructure, not in the actual report code. I believe there were some code changes implemented over the life of the 2.6 code series, and there were more changes in the transition to 3.x. I think the bottom line is that yes, different code releases will give different results with some data even if the report configurations are scrupulously checked to be identical. Now, where do we want to go from here? David Carlson On Sun, Feb 10, 2019, 3:17 AM Geert Janssens <geert.gnuc...@kobaltwit.be wrote: > Op zondag 10 februari 2019 09:56:51 CET schreef Adrien Monteleone: > > I’m in agreement on that note. I understand why someone who doesn’t close > > books would like a report that shows a current position. But the Trial > > Balance report is really only useful for the close books crowd. It should > > only reflect actual transactions in the various registers. In the case of > > assets then, it shouldn’t be estimating based on any user choice of > > average, nearest date or such, it should be taking actual purchase price > > just like you would if you did it on paper. > > In Belgium you have the choice (or at least used to have - I haven't > checked > lately): > We can/could report the balance using purchase values or using current > values, > with current values meaning current at the report date. > > Regards, > > 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
