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, or better, post them directly into the earliest year and any following years will automatically be updated as normal.

Checking if a voucher is fully posted

Sometimes due to some kind of system error a batch is not fully posted then one voucher in the batch may be half-posted. Any remaining vouchers in the batch (after/below) will almost certainly be completely unposted.

To see if this has happened, first identify which voucher is problematic and then check if the first and last lines of the voucher are correctly posted by seeing if the voucher appears in their respective ledger accounts.

First line is not posted

If the first line does not appear then probably the whole voucher is not posted at all.

Reposting the voucher may successfully solve the problem but see Reposting a batch and Cross Check Balance to avoid potential issues in reposting.

Last line is not posted

If the first line appears but the last line does not appear as posted in its ledger account then the voucher is "HALF POSTED". This breaks the all important law of double entry accounting and the trial balance will not balance.

Reposting the voucher will not solve the problem because the system does not take into account that the voucher is half posted when it is reversing the original voucher during the repost.

First and last lines are posted

In the case there is no problem. The voucher is fully posted and the half-posted issue is not present

Reposting a Batch in Journal Entry

The authorisation to repost a batch is restricted to NEOSYS and a few client users at the moment. Reposting a batch will repost all the vouchers in the batch.

See Correcting mistakes in postings for NEOSYS policy for correcting mistakes in journal postings.

Warning: Reposting journals which are already allocated will create cross check balance errors, so before reposting, any allocations should be de-allocated to avoid these errors.

Reposting a batch should be done in TEST dataset first. After reposting, all accounts should be tested for cross check balance errors. Do this by taking ledger printout for the whole year for all accounts.

See Procedure for Reposting Journal Entries

To repost a batch, edit the journal on the Journal Entry/Query page and save. Click OK for the prompt “OK to repost now?”.

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

Speeding up CHK.VOUCHERS CHK.ALLOC

When running the above programs takes time due to a large number of vouchers, then you can speed up the process by prebuilding a filter and using it on each invocation of the program. This filter is lost when you login again.

For example, if you want to check vouchers for account numbers XXXX, YYYY and ZZZZ in financial period 2004.01 and onwards

SELECT VOUCHERS WITH YEAR_PERIOD GE "14.01" AND WITH ACCOUNT "XXXX" "YYYY" "ZZZZ"

wait for it to say "xxxx record(s) selected" briefly and then show blank command line again, then type

SAVELIST XYZ

then each time just before you run CHK.VOUCHERS and CHK.ALLOC you can do the following to make them only look at the selected vouchers

GETLIST XYZ

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.

The voucher numbers will appear in the batch when the batch is re-saved. The same voucher numbers appears as it was in the voucher file.

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.

The voucher numbers will be generated when the batch is re-saved but not in sequence number. Notify clients the batches are re-saved and the voucher number will not be in sequence.

Solution

Run CHK.VOUCHERS and check for errors. Then re-save the batch.

The authorisation to re-save a batch is restricted to NEOSYS and a few client users at the moment.

Running CHK.VOUCHERS

Run the following command in maintenance mode and check for errors.

F5
UTIL
CHK.VOUCHERS  

When running CHK.VOUCHERS, respond to prompts as shown below. Generally respond negatively to prompts which are not specified below, but in TEST datasets you can experiment by responding positively.

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

Choose "All" for the following message. This is to keep the file "clean" of messages but does not actually cause any changes in the rest of the system.

Account "XYZ" is "JOBS", but the voucher analysis code "28*1*clientcode**marketcode*suppliercode*mediatypecode" is "MEDIA"
Fix voucher analysis code is to be JOBS and repost?

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

While running the command, monitor the lines coming up on the screen for any warnings. In case you make any changes and select "Yes" or "Yes to all" for any message, you should re run the command again until clean.

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!

CCB error for Wrong A/C can be fixed by running CHK.VINDEX

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.

Fixing "Index has been deleted" message

Error Message

The index record "TEXT.XREF*abc*xyz"
has been deleted.
The index for "TEXT.XREF"
should be rebuilt.

Solution

Perform REINDEXVOUCHERS in maintenance mode.

Removing strange outstanding items on accounts that have balance of zero

Sometimes running CHK.ALLOC on periods too far back in time causes old items to be incorrectly resurrected and become outstanding.

If the account balance is zero in the current period and has been for some years then you can simply delete all outstanding items.

Assuming the (original) account number is AAAA and the company code is CC, in maintenance mode, F5.

DELETE VOUCHER.INDEX *AAAA*CC

It should say "1 Item(s) deleted"

Using CHK.POST to fix some types of Cross Check Balance (CCB) errors

CHK.POST can be used to fix/recreate the BALANCES files. This could be useful in the following cases:

1. Some stubborn Cross Check Balance errors
2. BALANCES file is damaged (use FIXFILE first)

Use it strictly only after ALL other errors have been fixed using the usual CHK programs

• CHK.VOUCHERS
• CHK.VINDEX
• CHK.ALLOC
• CHK.BATCHES
• CHK.BALANCES
• CHK.ACCOUNTS
• CHK.CHARTS
• CHK.CONTROLS

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.

1. In maintenance mode press Alt+1
2. 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.
3. Press F9 and Esc
4. Press F5 and type CHK.POST
5. What stage to start at? Choose “Select Vouchers”
6. Clear the updated balances file? Choose “Clear it”
7. OK to Start? … OK
8. 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

1. 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.
2. 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".