Rich,I might be answering to the wrong threads, but the two items are related allright.
It might seem to be unrelated, but I have personal experience that proves itt: header accounts tend to mess up reports. Facts in the accounting package are fine, the reports are off the mark. I do not know why the reports are off. I mentioned it some years ago to Dieter and got no real explanation either. Then I simply removed ALL header accounts from the accounts scheme and presto: the errors where gone. I do not know WHY the trial balance report adds up wrong. The said 18.000 in your case, it was another amount in my case. It seems to me (might be a wild guess) that EITHER the subtotal is of by x rows before the actual row that should be added up. _OR_ the report counts x number of accounts (most likely header accounts) twice, since they have not been defined right. My guess is, one or more header accounts are wrongly defined as subtotal account (add all accounts between previous subtotal and this account up and print (use) the calculated subtotal). Shure, maybe the report logic should be rewritten, or the scheme analysed for erroneous account codes. Like Jean Pierre remarked correctly, there is a tack box to define if any account shows up in the drop down list for different menu. Since this is a user definable parameter it is not fair to say it is a bug. Just some configuration issue not tweaked 100% correct by the user. We can hardly blame the program there. The 'this is a summary account" tack box might also be defined wrongly somewhere, I do not know. But I am no programmer, checking all that seems like a LOT of work. And I was happy to see the problem go away when I removed the header accounts. Might work for you as well. Is it very hard for you to remove (or comment out) the headers from your scheme and rerun the report? All my worries where gone when I did that, that is why I suggested it in the first place. As a bonus, the wrong account will not be available in the drop down, being removed and all, probably leaving only the right one as default. Final question: you say the debit columns has an extra 18k, is the report out of sync? And if not out of sync, it might be helpfull to know where the report stores this 18k on the Credit side? You have any accounts with exactly 18K in them? HtH, Paul 2010/6/6 Rich Shepard <[email protected]> > On Sun, 6 Jun 2010, Paul Tammes wrote: > > The Header is just what it says: a header, NOT an account. So e.g. as a >> Header above 25 different bank accounts in the UK, you could use the >> header " UK bankaccounts" and then use another header for 15 differet USA >> bankaccounts and so on. This is good for the human readable form of a >> GL-scheme. But not at all needed for the accounting package to function >> properly. >> > > Paul, > > You appear to confuse the two issues I posted on separate threads. > > The header shows as the default A/P header when I select Cash -> Payments. > Each time I need to change the combo box selection to Accounts Payable from > Current Liabilities. My question was how to change the default selection of > that widget to Accounts Payable. The related question is why a header is > displayed in that widget. > > > Knowing that headers also tend to mess up reports (correction: the reports >> template code gets more difficult and might show surprising results when >> adding the header ledger in the result of additions or something like >> that)) it might be a good idea to get rid of headers alltogether. If eeded >> make an extra version of the GL-scheme with # commented out# header lines. >> > > The reporting issue is that the current balance of my checking account is > not displayed as the current balance in the Trial Balance report. Looking > closely at the two I see that it's the Debit column in the Trial Balance > report that has an additional $18,000 in it (and I wish that was in my > actual checking account!). > > Because the sum of debits in the checking account register are correct, I > ask where the Trial Balance report could have minted the additional money. > It is obviously not the sum of the checking account debit column. > > > Rich > _______________________________________________ > SQL-Ledger mailing list > [email protected] > http://lists.ledger123.com/mailman/listinfo/sql-ledger >
_______________________________________________ SQL-Ledger mailing list [email protected] http://lists.ledger123.com/mailman/listinfo/sql-ledger
