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
Voucher number missing from posted batches
In some cases voucher numbers are missing from posted batches.
There could be several reasons why the voucher numbers are missing. The voucher number is generated but does not reflect on the batch or the voucher number did not get generated at the time of posting. We are still investigating the root cause to this problem.
For both cases, take a ledger print out for the account the voucher number is missing and check if the voucher number is present in the ledger print out.
1. The entries in the batch reflect on the ledger print
If the entries reflect in the ledger print out, open the voucher file and investigate why the voucher number did not appear when the batch was posted.
Run the following command in maintenance mode.The voucher numbers will appear when the batch is resaved. The voucher numbers will appear as it was in the voucher file.
F5 UTIL CHK.VOUCHERS
2. The entry in the batch does not reflect on the ledger print.
If the voucher file is not present in the ledger print out, open the batch and investigate why the voucher number did not generate when the batch was posted.
Run the following command in maintenance mode.The voucher numbers will be generated when the batch is resaved but not in sequence number. Notify clients the batches are resaved and the voucher number will not be in sequence.
F5 UTIL CHK.VOUCHERS
Note that the authorisation to resave a batch is restricted to NEOSYS and a few client users at the moment.
Choose "Yes" for the following message:
Missing from batch but matching ref with no voucher can be found. Add it?
Choose "No" for the following message:
Delete empty unposted / deleted voucher ?
Choose "Yes or All" for the following message:
Account “ XYZ” type is “ COST” , but the voucher analysis code “28*1*COMPANYCODE*XYZ” is type “ BILL/INCOME” . Fix voucher analysis code to be COST and repost? :---- YES/ALL
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 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.
Missing Voucher - Delete the index entry?
╔═════════════════════════════════════════════════════════════════╗ ║ "*VIV*N" L=458 V=IN*2012/1170*N 29/05/12 missing voucher ║ ║ Delete the index entry? ║ ║───┬─────────────────────────────────────────────────────────────║ ║ 1>No ║ ║ 2│Yes ║ ║ 3│None ║ ║ 4│All ║ ╚═════════════════════════════════════════════════════════════════╝
Select Yes.
Different Date - Correct index entry?
"*OMD*AP" L=115 V=IN*2013/350*AP 31/03/13 B=1159
different date "14/03/13"
Correct index entry?
───┬─────────────────────────────────────────────────────────────
1>No
2│Yes
3│Correct None
4│Correct 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".
Solving Error: "Estimate 'xxxxxxx' system failure during previous invoicing attempt"
System errors during production invoicing can result in various degrees of partial updating of invoice files, finance journals and billing analysis reports.
It is important to stop further attempts to invoice an estimate until steps have been taken to reverse any partial updates done. Therefore, if there is a system error during an attempt to create an production invoice, the system locks the estimate from further invoicing.
You can unlock the estimate for another attempt at invoicing but the following preventative and defensive procedure must be followed meticulously to avoid making things WORSE not better.
Step 1. THIS PROCEDURE MUST BE RUN IN TEST DATA FIRST.
Step 2. A REPORT MUST BE MADE STATING THE IDENTIFIED CAUSE OF THE FAILURE AND WHAT STEPS HAVE BEEN TAKEN TO AVOID IT REPEATING. THIS STEP IS *NOT* OPTIONAL
Step 3. REPEAT THE PROCEDURE IN LIVE DATABASE ONLY IF A) THERE IS NO ISSUE IN STEP 1 AND B) STEP 2 HAS BEEN COMPLETED.
Identify the half created invoice number
LIST PRODUCTION.INVOICES INVOICE_NO_FAILSAFE WITH INVOICE_NO_FAILSAFE NE ""
Determine if any postings have been made
Locate invoice voucher in finance Voucher File and/or Journals and note the posted or unposted batch number.
If already posted: Reverse any posted finance journals
If the invoice journal has already been posted then get finance to create a corresponding journal to reverse it
If not yet posted: Delete any unposted financial entries
Delete the unposted invoice journal voucher from unposted journals
Notify finance department of the lost invoice/journal number
Delete the invoice from the database
Locate the invoice in the List of Invoices report. Your diligence is required to avoid missing it due to wrong selection of period etc. 99999 is the invoice number and X is the company code
DELETE INVOICES "999999**X"
If it says "Record does not exist" then also do
DELETE INVOICES "999999"
Run List of Invoices again to confirm it no longer exists.
Unlock the estimate
XXXXXX is the production estimate number
SELECT PRODUCTION.INVOICES "XXXXXXXXX"
It should say briefly "1 record(s) have been selected"
CLEARFIELD PRODUCTION.INVOICES INVOICE_NO_FAILSAFE
It should just come back to the command line immediately
Invoice the estimate
Create the invoice and check everything is OK
