There was an item with headers, which dissapered after I got rid of the headers. That solved the bug for me, and I can read a CoA without comments fine so for me it is no big deal. I can imagine some `normal`people may have more trouble reading a CoA without headers and comments.
I did not run a trial balance for a while, use balance and income statement most of the time. I just did run one in my test firm and found that if in SQL Ledger I go to > Reports > Trial Balance I get the option to choose a lot of things: Department, Period, Language, Standard or GIFI, and three tack boxes: Include in report: Headings / Subtotals / All accounts. Now as I explained, the use of headings gave me a lot of problems, so I suggest to make sure that one is NOT ticked. Might save the job of removing the headers from the COA alltogether. The subtotals might also throw the report out of whack, untick as well is my advise. Using all accounts on the other hand makes sense. I is just possible some hardly used account shows up with a balance of 18k exactly. If the trial balance report is NOT balanced, it is faulty. If it IS balanced, the 18k `added` to one account must be evened out on another account in my perception. Will use a CoA with headers in the test firm next, to see (make sure) if the header problem can indeed be solved that way. Would be a nice to have. Cheers, Paul 2010/6/7 Rich Shepard <[email protected]> > On Mon, 7 Jun 2010, Paul Tammes wrote: > > 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. >> > > Paul, > > So your P&L and Balance Sheet have no headers? Doesn't seem right to me. > Regardless, if the headers mess up reports then there's an unresolved bug > in > the report generating function(s). > > > 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). >> > > This should have nothing to do with headers vs. accounts in the CoA. The > Trial Balance report lists only accounts (at least, that's the default on > my > setup), and the issue is with a single account: the checking account that > heads the list. There's no header involved, but the summation of Debit > entries from the account transaction register to the summary report of all > account transaction registers. > > > 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. >> > > As you and Jean-Pierre write, headers are not accounts. Therefore, as I > interpret that headers should not show up in any list of accounts. > > > 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. >> > > I don't do perl, but I do write in C and Python. If my applications > behaved like I'm seeing in SL/L123 I'd go fix it. While I can follow perl > code with my finger along the lines and moving my lips while I read I've no > idea how to fix what appears to me to be incorrect logic or code. > > > 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. >> > > As I wrote initially, changing the defalut A/)P account displayed from the > header (Current Liabilities) to the account (Accounts Payable) on the add > A/P transaction page is more of a minor hassle than a big deal. If a > developer trips over the reason for this while looking at other things then > fixing it would be nice. Otherwise, there are more important things to fix > ... including why a debit total from an account transaction register has > $18,000 added to it when shown on the trial balance page. > > > 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? >> > > This issue is with a single account: my checking account. The credits in > the account are presented correctly in the trial balance. The debits gain > from one display to the other. Again, the transaction register matches the > bank statements (much as I would like to have that extra money available to > spend) so the issue is where the extra comes from when I request viewing > the > trial balance. > > > 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
