> > > ---------- Forwarded message ---------- > From: John Ralls <jra...@ceridwen.us> > To: Adrien Monteleone <adrien.montele...@lusfiber.net> > Cc: "gnucash-de...@lists.gnucash.org" <gnucash-de...@lists.gnucash.org> > Bcc: > Date: Sun, 10 Feb 2019 08:54:03 -0800 > Subject: Re: [GNC-dev] tb, gnc or me? my trial balance is wrong and I > think it is gnc not me > The "Average Cost" price source creates a price based on the actual > transaction prices and is designed for the TB report, see the thread > beginning with > https://lists.gnucash.org/pipermail/gnucash-devel/2008-July/023297.html. > I broke it for 2.6.13-2.6.21, see > https://bugs.gnucash.org/show_bug.cgi?id=775368. The "Average Cost" and > note that even 2.6.21 didn't fully fix it; that didn't happen until 3.2. > > Average cost is the *only* price source that works for the Trial Balance > Report. In particular the "Nearest in Time" and "Most Recent" sources will > take prices from the price database that are unlikely to reflect the actual > prices for the transactions and will vary depending on the date of the > report. I agree with Adrien that we should consider removing the price > source option from that report and hard-wire it to average cost. > > Regards, > John Ralls > >
It is possible that Wm is noting a problem in gnucash that I'm trying to address with my 'Book Currency' enhancement (unfortunately, a bit delayed). For most users who deal in a home currency most of the time and occasionally buy a foreign currency, say on a trip, and spend it on expenses, this deficiency won't show itself. But for people who deal in multiple currencies often, with complicated transactions, it may. Consider the following scenario: 1. A user is based in Europe and considers their home currency to be Euros 2. The user uses Euros to buy multiple lots of GBPs at different times. The transactions each have different implicit exchange rates in the individual splits, but gnucash doesn't do any automatic lot tracking. Some of the GBPs are used for expenses expressed in EURs. The splits associated with these expenses also have implicit exchange rates, but they don't have any relationship to the purchased GBP's costs unless the user makes carefull off-line calculations and enters the right amounts. 3. The user then uses left-over GBPs to buy USDs. The split entered into gnucash has an implicit exchange rate of USDs to GBPs but nothing expressed in Euros. If you want to run a report representing these transactions in Euros there is no way to do so unless you use an externally supplied exchange rate (e.g., from the price db) because the splits themselves don't have all the required information. If you want to run a report 'at cost', you also can't do this because item 3, above, doesn't contain the right information (so you have to 'fudge it' with an amount from the price db). This can be overcome procedurally in gnucash by using the trick of entering the #3 transaction in a register of an account denominated in Euros even if that account isn't involved in the transaction. One split will sell the GBPs in EURs, the other will buy USDs in EURs and as soon as you hit the enter key, the transaction will 'disappear' from the register it was entered in (since neither of the splits were for that account). The transaction, however, will show up in the registers for the accounts involved and they will contain the implicit exchange rates that were missing above (but not necessarily with any lot tracking and still requiring a lot of off-line calculations to figure out the right numbers to enter into the splits). Now a report 'at cost' could be run, but only if the trick was used procedurally for every transaction not involving the home currency. Of course, this can't be assumed to be the case. The 'book currency' feature is intended to deal with this by, if the 'book currency' feature is selected, forcing every non-book-currency split to be denominated in book-currency (i.e., like the trick, above, but without having to use a third account register) and enforcing lot tracking for each of these transactions (to get rid of all the off-line calculations), thus providing a basis for tracking cost and eliminating the need for an external price reference (unless you want to see an estimate of current value). I don't know if this is related to the problem Wm is seeing, but it might be. Alex _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
