.title "Total-to Orphan Search"
.id 314120060210135306
.tags "manual"
.body {
	[h1 "Proof Accounts"]
	[h3 "What is a proof account?"];
	[p {
		There are no officially designated [qw_term proof] accounts in NewViews.

		A proof account is simply an account that you have wired up in such
        a way that you always expect its balance to be zero.

    }]
	[img .src c:/cpp/tcldot/proof2.gif]
	[p {
		The graph above is an overly simplified version of a typical set of books
        showing two proof acounts in yellow.

		Do not copy the structure above for your set of books as the structure
        of the trial balance and the management of retained earnings were simplified
        due to space constraints.

		All transactions in a set of books will post either to accounts on the trial balance or to accounts
        on subsidiary ledgers such as receivables and payables that in turn total to
        controlling accounts on the trial balance.

        All of the trial balance accounts in turn total to [qw_field_value TB-PROOF] account.

        Therefore, all transaction postings should affect accounts on the trial balance
        either directly or indirectly and the balance of the trial balance proof account should always be zero.
    }]
	[p {
		Note that the proof account is just a total account which happens to be totalled to
        from all of the accounts on the trial balance.

        It is not special in any explicit way.
    }]
	[p {
		The balance sheet and income statement draw their amounts from accounts on the trial balance,
        and organize things little more by providing expected report sub-totals.

 		In addition BS-PROOF has been added to the balance sheet, providing yet
        another proof account whose balance should always be zero.

    }]
	[p {
		Form the example above the following points above proofs in NewViews are worth
        mentioning:
    }]
	[ul {
		[li {
			[p {
				There is no officially designated proof account type in NewViews.
            }]
			[p {
				BS-PROOF and TB-PROOF are total accounts that will always be zero
                because all accounts you post to eventually total to them.

                Since the debits equal credits for reach transaction, the debits and
                credits reaching the proof accounts will always cancel each other out,
                and the balance remains zero.
            }]
        }]
		[li {
			[p {
				You can have more than one proof account.
            }]
			[p {
				In the example there are two proof accounts, but in general there no limit.

                For example, if you keep several accounting entitiies,
                departments, or branches in a set of books, you will probably keep one or
                more proof accounts for each.
            }]
        }]
		[li {
			[p {
				A proof account doesn't total anywhere.
            }]
			[p {
            	A proof account is the [qw_quoted "end of the line"] and it will
                not total anywhere else.

                If a proof account does total to another account, that account would typically
                also be a proof accuont anyway.
            }]
        }]
		[li {
			[p {
                The root account is a proof account.
            }]
			[p {
                In NewViews the total debits and credits are always equal, and therefore
                the books are always balanced in this sense.

                All accounts automatically total to the root account (/OBJECT/NEWVIEWS/ACCOUNT)
                and hence its balance is always zero.

                In this sense the root account serves as an overall proof account of sorts
                but it isn't particularly useful in the context of a particular
                total structure.

            }]
        }]
    }]
	[h2 "How can the books go out of balance?"]
	[p {
		It is fair to say that in many commercial accounting systems the books
        should never be able to go out of balance.

		So the question arises: why can they go out of balance in NewViews?

		Keep in mind that debits and credits are always equal and the books are
        balanced in that sense.

        What we mean here by the term [qw_quoted "out of balance"], is that a proof
        account has a non-zero balance.
    }]
    [p {
        In NewViews, financial statements, such as the trial balance, the income statement
        and the balance sheet are constructed by the user, using the total-to structure of NewViews,
        i.e. the [qw_field_name "total to"] fields of the accounts.

        Amounts displayed on total accounts therefore only have the meaning
        a user gave them when wiring up the total-to structure.

        This puts a great degree of flexibility into the hands of the NewViews user, but
        at the same time, it is the user's presponsibility to hook accounts into the
        total-to structure.

		Other systems do not go out of balance because they cannot be configured to
        do so.


    }]
	[p {
        We will now go through the various scenarios underwhich a set of books
        either goes out of balance or appears to be out of balance.
    }]
	[ul {
		[li {
			[p {
				You forgot to hook up an account's total tos."
            }]
			[p {
				This is by far the most common reason a proof account has a non-zero balance.

				You forgot to hook the total to of an account somewhere.

                I could be the a posting account or a total account somewhere above a
                posting account, whose total to was not hooked up.

				See ??? Orphan Search for a way to find these so-called [qw_term orphan] accounts.
            }]
        }]
		[li {
			[p {
				bookmark 314120110406173213
				You have used a NV1-syle journal transactions and the specialized JOURNAL_BAL account.
            }]
			[p {
				Some users, mostly NV1 veterans, like to enter transactions solely on the transaction details,
                which we refer to as NV1-style journal transactions.

                Using this technique, no account is selected in the transaciton header.

                Instead, an account is posted to from each detail,
                and the corresponding balancing amount for the detail is posted
                to a special account; usually JOURNAL_BAL.

                Using this technique it is essential that the total amount of each transaction must be zero.

                That is, the transaction's running balance will go up and down as
                details are added but it must end in zero, and the header amount must be zero.

                This also guarantees that the JOURNAL_BAL amount will be zero.

				If the JOURNAL_BAL amount ever goes non-zero, then the proof account
                will go non-zero on the same date, and will the running balance of
                the journal containing the errant transaction.
            }]
        }]
		[li {
			[p {
				Your budget is out of balance.
            }]
			[p {
				NewViews does not attempt to balance budget amounts.

				If you enter budget amounts directly on a report, the amounts will be
                posted to an account using a budget transaction and the amounts balanced
                to a BUDGET-BALANCE account (similar to way the JOURNAL_BAL account
                is used as mentioned above).

				Using this technique, a proof account will show non-zero amounts when
                the budget tag is selected.

				Note, alternatively, you can add budget transactions to a journal set for
                budget amount tags, and you can keep you budgets balanced just as you
                do for financial amounts.
            }]
        }]
		[li {
			[p {
				Allocation tag amounts are out of balance.
            }]
			[p {
				Allocation tags are selected on a transaciton by transaction basis
                and they are not balanced at all.

				Therefore there is no expectation that proof accounts will have a
                zero balance when allocation tags are selected.

				See ???.

            }]
        }]
		[li {
			[p {
				There is a bug in NewViews.
            }]
			[p {
				If the root account has a non-zero balance, it can only be
                due to a bug in NewViews.

                We suggest that you reorganize the database in this case.

                This occurrence is exceedingly rare and has not been seen by PAGE
                staff to date.

            }]
        }]
    }]

	[h1 "Total-to Orphans"]

	[img .src totalto_orphan_search_splash.gif]

    [h2 "What is an Orphan Account?"]

	[p {
		An [qw_term orphan] is an account that does not total to each account
        in a set of one or more proof accounts.
    }]
	[p {
		In the graph above, [qw_field_name PROOF] is a [qw_term proof] account,
        and [qw_term F], [qw_term B], and [qw_term A] are the orphans because
        they do not total to PROOF.

		An account is an orphan only in the context of a set of one or more proof accounts.

		Pick a different set of proof accounts, and you will have a different set of orphans.
    }]
	[p {
		Above, [qw_term F] is a [qw_term posting] orphan because it is a posting account, whereas [qw_term B]
        and [qw_term A] are [qw_term total] orphans.

    }]

    [h2 "The Orphan Search Command"]
    [p {
		When a set of books is out of balance, meaning a proof account has a non-zero
        balance, it is almost always because somewhere you forgot to hook one of more accounts
        into the totaling structure of NewViews by connecting their total to fields.

		You can position on the problem proof account and issue the [qw_menu_command Tools TotalTo "Orphan Search"] command
        to create a report that lists all posting account orphans for the selected proof account.

		Another way to search for orphans is to position on the proof check view of the NewViews object (/OBJECT/NEWVIEWS), (introduced in version 2.21),
        and issue the same orphan search command.

		Each proof check item has a list of one of more proof accounts and when you
        issue the orphan search command that list of proof command is used for the
        orphan search.
    }]
	[h3 "Why only posting accounts?"]
    [p {
		An orphan search only lists posting account orphans because they are the
        ultimate source of the non-zero proof account amounts.

		To see why we don't want total accounts in the orphan list, consider the
        following.

		Suppose you specify the trial balance proof account and generate it's orphans.

		Suppose further that all posting accounts in the set of books total to the proof account
        so the proof account amounts are all zero (i.e. the books are balanced).

        If total accounts were also listed, then even when there are no problems
        a large number of accounts would be reported as orphans.

        That is because many posting accounts, in addition to totaling to the proof accounts,
        are often also hooked up to summary totals that do not total to the
        proof account.

		Hooking them up this way is fine, and very useful, but there is no need
        to report the summary total accounts as orphans.
    }]
	[h2 "How to use the orphan search command."]
	[h2 "Orphan Search on a table of Accounts"]
    [p {
		The command is [qw_menu_command "Tools" "Totalto" "Orphan Search"] and
        it is available on a table of accounts (blue) or on the proof check view
        of the NewViews object (/OBJECT/NEWVIEWS).

		The only difference is the way the set of proof accounts is specified.
	}]
    [p {
		When on a table of accounts, the account you are positioned on is the
        specified proof account.

        So you just position on a proof account and issue the command.
	}]
	[h2 "Orphan Search on the proof check view."]
    [p {
		When on the proof check view, the row you are positioned on has a set
        of one or more proof accounts, and that set of proof account is used if you issue the
        orphan search command on that row.

		This is very useful because it often eliminates the need to run multiple orphan searches.

		When you use a set of proof accounts in this manner, each posting account
        must total to all of the proof accounts in the set or else it
        is deemed to be an orphan and is added to the orphan list.
    }]
	[p {
		Suppose you have a proof check row that has TB-PROOF and BS-PROOF in it's set of
        proof accounts.

		This is a common and useful example.

		Running an orphan search on this row is equivalent to running two orphan searches,
        once for each proof account.

        It is entirely possible that you might hook a new trial balance account to
        TB-PROOF but forget to hook it into the income statement or balance sheet,
        and thus it never reaches BS-PROOF.

		If you run an orphan search on TB-PROOF alone, the errant account will not
        show up.

        It will only show up in the oirphan list of the BS-PROOF account.

		Howoever, by running an orphan search on the proof check row that includes
        both BS-PROOF and TB-PROOF, you will detect the errant account with only one
        operation.
    }]
	[h2 "Orphan search and security."]
    [p {
        Only users granted access to the root account (or any object above it) can
        perform an orphan search.

        Otherwise it would be a breach of security since lists of accounts to
        which the user has not been granted access could be displayed.
    }]
	[h2 "Orphan search and special accounts"]
    [p {
		Three accounts will typically show up in a orphan search:

    }]
	[ul {
		[li {
			[p {
				BUDGET_BALANCE - Budget Balance
            }]
			[p {
				This account contains unbalanced budget amounts.

                No attempt is made to balance budget amounts and there should be
                only budget amounts (i.e. never financial, order or other amounts)
                in the BUDGET_BALANCE account.

				It will always appear in an orphan search and you can ignore it.
            }]
        }]
		[li {
			[p {
				JOURNAL_BAL - Journal Balancing Transactions
            }]
			[p {
				This holds the balancing amount from NV1-style journal transacitons (See bookmark 314120110406173213).

				It will always appear in an orphan search and you can ignore it.


            }]
        }]
		[li {
			[p {
				JOURNAL_ERRORS - Journal Entry Errors
            }]
			[p {
				This account is used when importing unbalanced journal entries from NV1.

				It is a temporary repository for unbalanced NV1 journal transactions
                that need to be properly re-allocated.

                Although this account will appear in an orphan search it will generally be empty and can be ignored.
            }]
        }]
    }]

	@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
	@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

	[p {
		Use this command to find all accounts that do [bold not] total to a
        specified [qw_term proof] account.
    }]
	[p {
		A major purpose of this command is to help determine why a set of books is
        [bold "out of balance"].
    }]

	[p {
		A typical NewViews set of books can have any number of so-called proof accounts.

        We define a [qw_term proof] account as a total account whose balance should always be zero.
    }]
	[p {
		A typical set of books will usually have proof accounts such as:
    }]
	[ul {
    	[li {
			[p {
				Trial Balance Proof Account
            }]
			[p {
				All posting accounts should either appear on the trial balance,
                or else should ultimately total to an account on the trial balance.

				All accounts on the trial balance should in turn total to the
                trial balance proof account, and the balance of that proof account
                should always be zero.
            }]
        }]
    	[li {
			[p {
				Balance Sheet Proof Account
            }]
			[p {
				The balance sheet draws amounts from the trial balance,
                or in the case of retained earnings, from either the trial
                balance or the income statement.

                The income statement in turn draws its amounts from the trial balance.
            }]
			[p {
				Accounts on the balance sheet total forward ultimately to the total
                assets account, or to the total liabilities and equity account.

				These two account should always balance.

                Often one just looks at the balances of these accounts to check
                that the balance sheet [qw_term balances].

                However, many, if not most, sets of books total these two accounts
                to a balance sheet proof account, and the balance of that proof account should
                always be zero.
            }]
        }]
    }]
	[p {
		When the balance of a proof account is non-zero you have a problem.

        This command is designed to help find the source of that problem by
        searching for [qw_term orphans].
    }]
    [h2 "What is an orphan?"]
    [p {
        An orphan is an account that doesn't total to a specified account.

        The specified account of interest is almost always a proof account, as
        described above.
    }]
	[h2 "How to use this command."]
	[ul {
		[li {
            [p {
				Position on a proof account whose orphans you want to find.
            }]
			[p {
				For example, if the trial balance proof account is non-zero,
                position on the trial balance proof account.

                That is, move to any table of accounts (blue) that contains the
                trial balance account proof account.

                It will appear on a table explorer that has all accounts,
                or you can find it on the trial balance report.
			}]
            [p {
				We use the trial balance proof account as an example but the
                same method is used for any proof account that is non-zero, i.e. out of balance, such
                as the balance sheet proof account.
            }]
        }]
		[li {
			[p {
				Issue this command.
            }]
			[p {
				This command will search through all accounts in the database so
                you will be prompted for confirmation.
            }]
        }]
		[li {
			[p {
				A report of the results is displayed in a separate window.
            }]
			[p {
				All accounts that do not total to the proof account, i.e. the so-called orphans,
                are displayed by the report.

                There is a separate table for all orphans that are postings accounts,
                for all orphans that are total accounts, and a summary
                of the most suspicious total account orphans.
            }]
			[p {
				Each table is described in more detail in the report itself.
            }]
        }]
    }]
	[h2 "Amounts on the orphan report."]
	[p {
		An amount is displayed on the orphan report for each orphan account.

		By default the tag for the amount is [qw_field_value financial] and the
        period includes all transactions, that is from the beginning of time to the end.

	}]
    [p {
		However, if you are positioned on an amount cell in the blue table row
        when you issue this command, the amounts displayed in the orphan report
        respect the tag and perdiod selected for that cell.

		When books are out of balance, the amounts can be useful clue when
        hunting for the cause.
	}]
    [p {
		For example, suppose the trial balance proof is non-zero and more
        specifically, the financial amount for Dec 31, 2005 is out by [qw_field_value 123.45].

        If you position on that amount field and issue this command, then the amounts
        displayed for all accounts on the orphan report will be for financial amounts
        as at Dec 31 ,2005.

		If there is a posting account orphan with the amount [qw_field_value 123.45]
        you have a pretty good idea that this account is implicated as a cause of the balance problem.

		It is likely that the posting account's total to's should have been hooked
        up to an account on the trial balance but weren't.

        Or there could be a number of posting accounts on the orphan report that
        sum to [qw_field_value 123.45], and all of them should have been hooked up
        but weren't.
	}]
    [p {
        The point is that the amounts add useful information when tracking down the
        cause of the books being out of balance.
    }]

    [h2 "How can orphans be a problem?"]

    [p {
        The short answer is that orphans can cause a set of books to
        look like it is out of balance.
    }]
    [p {
        First note, that a NewViews accounting database, also known as a set of books,
        always balances to some degree in the sense that debits
        always equal credits, and the root account always has a zero
        balance, providing the ultimate proof.
    }]
    [p {
        But financial statements, such as the trial balance, the income statement
        and the balance sheet are constructed by the user, using the total-to structure of NewViews,
        i.e. the [qw_field_name "total to"] fields of the accounts.
    }]
	[p {
		Amounts displayed on total accounts therefore only have the meaning
        the user gave them when wiring up the total-to structure.

        This puts a great degree of flxibility into the hands of the user, but
        at the same time, the user may omit to hook accounts into the
        total-to structure.

        The usual first indicator of omissions of this type are non-zero
        proof accounts, or more generally, that the books do not appear to
        balance.

		This command is designed to help you isolate these omissions so that
        they can be fixed.
    }]




}