Troubleshooting NEOSYS Finance System
Cross-Year Cross Check Balance Warnings
When you use Opening Balance Journals, NEOSYS does not guarantee that the opening balances of one year match the closing balance of a prior year. This occurs quite normally and commonly occurs in two situations described below.
Regardless of the cause, in such cases, any statement or ledger account of movements (not open items) that crosses the disjoint years will have a "cross check balance" note at the bottom of the account. A cross check balance warning is just a warning that the closing balance of the account (as calculated from a simple total of the opening balance in the old year plus all transactions) does not agree with the actual account balance according to the trial balance in the new year.
If the opening balance of the account in the second year is not equal to the closing balance in the prior year then logically the two years cannot be viewed as a single continuous account and agree with the trial balance.
Producing Historical Accounts
When you start up a company in one year using Opening Balance Journals then the closing balances of the prior years remain zero. If you thereafter start to post into prior years, the closing balances of those years will remain in disagreement with the opening balance of the following years.
Opening Balance Journals
If you post Opening Balance Journals into one year for any reason, they are not posted into prior years. Therefore the opening balances of the amended year become different from the prior year.
In this respect, auditors amendments to opening balances should be posted as normal journals in the final period of the prior year and not as Opening Balance Journals in the current year.
Solution
If you wish to obtain cross-year accounts between years, and you wish such account's balances to agree with the later year trial balance, then you must arrange for the closing balances of the prior years to agree with the opening balances of the following years.
To do this, ensure that any Opening Balance Journals that are posted into any particular year are also posted into all prior financial years of interest.
Editing and Reposting Vouchers
WARNING: Can cause effectively irreversible damage to the finance database requiring restoration of a suitable backup causing loss of data and/or total loss of database if backup not available.
It is almost impossible to edit and repost vouchers and keep the audit trail correct so this procedure is of limited use. The stages are UNPOST, EDIT, REPOST.
Must be done on test data and advisable to run CHK.VOUCHERS afterwards.
UNPOST
F5 UNPOST XXX*YYYYY*ZZZ
Where:
- XXX is the voucher type/journal code
- YYY is the voucher number
- ZZZ is the company code
Any problems with the voucher might generate messages but the problems will be reverse the problems which must have occurred when posting the voucher in the first place.
EDIT
F5 ED VOUCHERS XXX*YYYYY*ZZZ
For example, if due to a neosys system error, the ZZZ999 suspense account has been used instead of some missing internal system accounts like exchange gain/loss accounts then you can insert the correct account.
Change line 8 (which contains the account numbers) from:
REZO²REZO²BMDI²BMDI²²
to
REZO²REZO²BMDI²BMDI²EXDI²EXDI
where EXDI is the A/c No. of the Exchange Difference A/c.
F9, ESC to save and exit
REPOST
F5 REPOST XXX*YYYYY*ZZZ
Using Finance Maintenance Mode fixing tools
Do not do mass fixes eg “Add/Delete ALL xyz” options from a year in the past eg 2007 while only checking accounts for 2009. You must CHECK EVERYTHING THAT YOU REQUEST TO BE FIXED.
The various fixing tools like CHK.ALLOC etc are impossible to make safe in all circumstances so if you don’t really know what you are doing you assume the WORST not the BEST with these fixing tools.
CHECK EVERYTHING YOU “FIX”!!!
IF YOU DO NOT FOLLOW INSTRUCTIONS CAREFULLY YOU CAN END UP MODIFYING AUDITED ACCOUNTS AND IT WILL TAKE DAYS FOR PROGRAMMERS TO TRY AND CORRECT THE DAMAGE YOU CAUSE OR EVEN REQUIRE A RESTORE OF A BACKUP CAUSING LOSS OF MANY DAYS WORK TO THE CLIENT
Fixing "Cross Check Balance" warnings using CHK.ALLOC
Cross Check Balance Message on an account means the total of the outstanding items in an account does not match the balance as in the movement - typically the outstanding shows a higher balance than the balance in the movement, but might not always be the case. The reasons why this may happen is because of the following:
- Reposting journals containing allocated items (which NEOSYS doesnt handle in all circumstances)
- Failing to clear open item accounts on a regular basis where the number of postings is high
This procedure only applies to CCB on the outstanding item type statements which are the more common problem. CCB on movement accounts are rarer, more serious and cannot be fixed by this procedure.
This might not always fix the CCB warnings and hence you will need to escalate to the programmer.
!!! WARNING This is a dangerous procedure. IF YOU DO NOT FOLLOW INSTRUCTIONS CAREFULLY YOU CAN END UP MODIFYING AUDITED ACCOUNTS AND AUDITORS/ACCOUNTANTS AND IT WILL TAKE DAYS FOR PROGRAMMERS TO TRY AND CORRECT THE DAMAGE YOU CAUSE!
This can be run while other users are online.
DO THIS ON TESTDATA FIRST
This exact procedure restores vouchers missing from open item accounts. This can be caused by:
F5 UTIL (nothing happens at this stage as its a background process and gives you access to the next command) CHK.ALLOC
Minimum voucher year.period?
Generally go back as little as possible to cover vouchers that might be missing from O/I accounts.
Which account do you want or blank for all?
You MUST press Esc to search for all accounts. Entering one account WILL NOT WORK since it will only check vouchers already on the open item accounts and we are looking for those that are missing.
IGNORE OR RESPOND NEGATIVELY to all messages or questions EXCEPT the following:
Missing from O/I index?
Select "Yes" or "Yes to all"
Meaning of other messages
The following message pair does not usually cause cross check balances and indicates that they have cancelled some foreign currency allocation since allocation should not cause and change in rate.
IN*175510*C 20/01/08 ALMA 4/2 REC*4440*C allocation base outstanding -7326.15 expected -6762.60 (-563.550,.08333333) IN*175510*C 20/01/08 ALMA 4/2 REC*4440*C allocation changed exchange rate from .08333333 to .07692308
Following MUST choose "Leave all" otherwise risk damage to closed audited prior year accounts:
Account numbers do not agree. Delete the allocation?
Following MUST choose "Leave all" otherwise risk damage to closed audited prior year accounts:
Allocation is missing ?
Choose "Skip further Warnings" for the following message:
Amounts do not agree - please fix manually
Re-enabling CCB warning mail notifications
NEOSYS is pre-configured to send out email notifications (to the same group of people who receive the backup alerts) when a Cross Check Balance (CCB) warning is found for the first time on an account. That means there will be only 1 email notification irrespective of the times the warning occurs until it is fixed.
After the CCB is fixed or after clearing or otherwise eliminating the same, you need to delete the CCB file in D:\neosys\neosys to re-enable NEOSYS to resend notification by email after it discovers CCB warnings on that account again in the future.
Fixing "Cross Check Balance" warning using CHK.VINDEX
YOU MUST READ AND APPLY THE GENERAL INSTRUCTIONS WRITTEN FOR CHK.ALLOC AS WELL FOR CHK.VINDEX
This program can fix a few CCB warnings that CHK.ALLOC cannot - including some in balance forward type accounts (ie not open item/outstanding item accounts) .
Not all the possible fixes are described here and any messages which are not described here should be responded to NEGATIVELY!
Different account - Delete the index entry?
"*MEVEJ*FZ" L=232 V=REC*461*FZ 05/07/09 B=447 "MEVEJ"
different account "ADVOPME"
Delete the index entry?
───┬─────────────────────────────────────────────────────────────
1>No
2│None
3│Yes
4│All
Select Yes.
Using CHK.POST to fix some types of Cross Check Balance (CCB) errors
This program adjusts the balances in the trial balance reports (which also show in the “Cross Check Balance phrase on the Detailed Ledger Accounts) to match the vouchers found in the voucher file. Note that CHK.ALLOC and CHK.VINDEX have no effect on these figures and instead amend the transactions shown on the Detailed Ledger Account - and thereby the totals on the same report so that they agree with the CCB amount and thereby the conflict is resolved.
Most CCB in NEOSYS are related to problems on outstanding item accounts and are fixed with the CHK.ALLOC program. More rarely, problems occur in the movement accounts and are fixed with the CHK.VINDEX program - although this can also fix some errors in outstanding item statements. Even more rarely will the problem be on the Trial Balances/CCB balances and can be fixed with this CHK.POST procedure
WARNING! This solution may make things worse so don’t use on live data unless EXHAUSTIVELY checked that everything is ok on test data first.
WARNING! Don’t go back and “correct” previous years which have been closed because auditors expect them never to change (EVEN IF THEY ARE WRONG!) and it can be impossible to put them back “wrong” if you “correct” them.
WARNING! If you correct previous years then you must rerun the Open New Year procedure for all prior years and this procedure is not documented and can only be run by programmers at the moment.
- In maintenance mode press Alt+1
- Enter the range of periods that you want to check/adjust the trial balance for e.g. 1/9-7/9 for 1st Period of 2009 up to the 7th period of 2009.
- Press F9 and Esc
- Press F5 and type CHK.POST
- What stage to start at? Choose “Select Vouchers”
- Clear the updated balances file? Choose “Clear it”
- OK to Start? … OK
- If there are any discrepancies found between the Trial Balance Balances/CCB balances … and the Vouchers in the file you will get some fairly cryptic questions asking you, one by one, if you want to fix the balances.
IMPORTANT
- It is advised that you only fix the balances which refer to the accounts that you are concerned about. You will find the account number buried in the cryptic questions referred to above.
- If you fix subsidiary account balances then MAKE SURE that you also fix the control accounts balances (if you are prompted).
B10 & B12 Errors
The error might be displayed as follows :
ERROR NO: B10 IN DAYBOOK.SUBSX AT 133 Variable has not been assigned a value. Zero used.
This error should have said something like : "The ledgers are closed up to the period you have just tried to post" OR "Financial Year 2011 must be opened before you post into it."
Try again and you would see the exact message if you have not opened the new year as yet.
Reinstating Open Item Statements after Clear Open Items
WARNING: DO THIS PROCESS ON TEST DATA FIRST TO VERIFY THAT IT DOES NOT CAUSE CROSS CHECK BALANCE ERRORS
WARNING: THIS PROCESS MAY CAUSE CROSS CHECK BALANCE ERRORS BY REINSTATING "ANCIENT CORRUPT VOUCHERS"
"CHECK BACK" AS FEW YEARS AS NEEDED TO INCLUDE ALL VOUCHERS THAT COULD BE OPEN/OUTSTANDING AT THE DESIRED PERIOD.
It is not easy to know how far to "check back" for open items so go back two years initially unless it is known that there may be items outstanding from even earlier years.
1. Check, solve, record all existing cross check balances
Restoring open items may create cross check balance errors so first you need to fix all EXISTING cross check balance errors in the database.
Do not proceed to the next step until this step is complete otherwise you will have no idea what problems were created by CHK.ALLOC and what problems were in the database before.
Expect no sympathy from programmers if you ignore this or fail to work on testdata first.
First print ***ALL*** open item ledger accounts to check for existing cross check balances in open item accounts.
Correct all "cross check balances" using the usual procedures to do so.
Note that cross check balances are unavoidable on some *extremely large* open item accounts. This does not mean that you can ignore cross check balances on merely large accounts. They must be fixed.
Save copies of the detailed ledger accounts of any *extremely large" open items accounts that you have not fixed their cross check balances.
2. Edit back the Company File "cleared-upto period"
Complete this step quickly if users are working online - in order not to lock the company file for longer than it takes to change the "cleared upto period".
In maintenance mode, press F5. example company code X. Do this for all companies that need to.
ED COMPANIES X
change line 17 to be the last period (YYMM) desired to have been cleared.
DONT add or delete any lines!
F9, Esc
3. Run CHK.ALLOC
This process can be run while users are working since there is a only a very slight chance that they will be posting the same account at the time that the program is updating its open item voucher index.
In maintenance mode press F5
CHK.ALLOC
Minimum is how far to go back. See explanation above.
╔═══════════════════════════════════════╗ ║ Minimum voucher year.period to check? ║ ║ (0 for all) ║ ║<200801 >║ ╚═══════════════════════════════════════╝
Which account do you want? PRESS ESC (or Enter+Esc)
╔═════════════════════════════════════════╗ ║ Which account do you want ? ║ ║ ║ ║ Give the account number or name, ║ ║ or press [Enter] if not known. ║ ║ (separate multiple entries with spaces) ║ ║< >║ ╚═════════════════════════════════════════╝
Add it? ... Choose "Yes to All"
╔═══════════════════════════╗ ║ Missing from O/I index ║ ║ Add it? (1.1KB) ║ ║───┬───────────────────────║ ║ 1│Yes ║ ║ 2│No ║ ║ 3>Yes to all <-THIS ONE ║ ║ 4│No to all ║ ║ 5│Yes to all *HAEX*FZ ║ ║ 6│No to all *HAEX*FZ ║ ╚═══════════════════════════╝
4. Check for cross check balances
Print ***ALL*** open item ledger accounts to check for any additional cross check balances in open item accounts.
If you have any ADDITIONAL cross check balances compared to those recorded in step 1, then you can rerun step 3 and "check back" a little earlier. Try one year earlier at a time - to avoid the problem of reinstating "ancient corrupt vouchers".
