Troubleshooting NEOSYS Finance System

Using Finance Maintenance Mode fixing tools

Follow the instructions below before you proceed with fixing CCB errors with any check/fix:

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”!!!

Do not go back risking fixes in prior years for which Finance has been closed, unless absolutely necessary.

While checking/fixing a CCB error, check and fix any other errors if present to avoid CCB's in future.

After doing check/fixes, all accounts should be tested for cross check balance errors. Do this by taking ledger printout for the whole year for all accounts.

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

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 the 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.

Posting into years prior to Opening Balance

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.

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.

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.

Producing Historical Accounts

As mentioned above, if you post Opening Balance Journals into one year, they are not posted into prior years. For such accounts, NEOSYS will show Cross Check Balance warning if you take a ledger account or statement of account report across multiple years including years prior to the Opening Balance Journal posting. e.g. if an account has opening balance entry in 2011, and no entries in 2010, then ledger account report with period setting 2010 - 2018 will show Cross Check Balance warning.

Solution

To avoid this Cross Check Balance warning, in the report period settings exclude years prior to the Opening Balance Journal posting, since the account anyway has no entries in the prior years.

Producing P&L and Retained Earnings Accounts

Refer to CCB on P&L and Retained Earnings accounts

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!

DO THIS ON TESTDATA FIRST

This can be run while other users are online.

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:

• Exodus TEST Database

1. /root/neosys/test <DBCODE>
2. After startup press "x" key.
3. Type: "chkalloc"

• Exodus LIVE Database

1. Stop all LIVE processes. (pressing x won't return prompt to enter check command if other LIVE processes running)
2. Run /root/neosys/run <DBCODE>
3. After startup press "x" key.
4. Type: "chkalloc"

• AREV Both LIVE and TEST databases

 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

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

2. For the following message, you MUST choose "Leave all" , otherwise risk damage to closed audited prior year accounts:

Account numbers do not agree. Delete the allocation?

3. For the following message, choose "Add it to other voucher" ONLY for the voucher/account that needs fixing. Do not choose "Add all" unless you know each and every allocation that will be added, as it could cause problems such as allocating to vouchers that are already allocated i.e. causing double allocations. You MUST check everything that you request to be fixed.

Allocation is missing ?

4. For the following message, choose "Skip further Warnings":

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?

51841 voucher_index recs
"*P831*1"  L=8 V=PUR*180123*1 30/06/18 B=13653 "P831" different account "P823"
========================================
"*P831*1"  L=8 V=PUR*180123*1 30/06/18 B=13653 "P831" different account "P823"                                    
Delete the index entry?
*1. No
 2. Yes
 3. Delete None
 4. Delete All
 Please enter 1 - 4 or Enter to default or 0 to cancel.
? 1

Select Yes.

Missing Voucher - Delete the index entry?

2500. *JOB4714*1"1401*815*1ü815"  "1ü815" bad company
"1401*815*1ü815"  L=1 V=PUR*11516:7*1ü815 15/01/14 missing voucher
========================================
"1401*815*1ü815"  L=1 V=PUR*11516:7*1ü815 15/01/14 missing voucher                                                     
Delete the index entry?
*1. No
 2. Yes
 3. Delete None
 4. Delete All
 Please enter 1 - 4 or Enter to default or 0 to cancel.
? 1

Select Yes.

Different Date - Correct index entry?

"*P831*1"  L=8 V=PUR*180123*1 30/06/18 B=13653 different date "12/02/18"
========================================
"*P831*1"  L=8 V=PUR*180123*1 30/06/18 B=13653 different date "12/02/18"        
Correct index entry?
*1. No
 2. Yes
 3. Correct None
 4. Correct All
 Please enter 1 - 4 or Enter to default or 0 to cancel.
? 1

Select Yes.

Commit or Revert current changes

Finished in 2 mins, 45 secs
What next boss ?
========================================
Commit any database updates ?
 1. Commit
 2. Rollback
 Please enter 1 - 2
? 0

Select 1 to commit changes.

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

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

This exact procedure restores vouchers missing from open item accounts:

• Exodus TEST Database

1. /root/neosys/test <DBCODE>
2. After startup press "x" key.
3. Type: "chkvouchers"

• Exodus LIVE Database

1. Stop all LIVE processes. (pressing x won't return prompt to enter check command if other LIVE processes running)
2. Run /root/neosys/run <DBCODE>
3. After startup press "x" key.
4. Type: "chkvouchers"

• AREV Both LIVE and TEST databases

 F5
 UTIL (nothing happens at this stage as its a background process and gives you access to the next command)
 CHK.ALLOC

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?

After doing check/fix, all accounts should be tested for cross check balance errors. Do this by taking ledger printout for the whole year for all accounts.

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
• CHK.OB (As of 12/2/19: Only Bates and AdlineD can parameters be entered in UI, whereas in TEST and other clients, editing of program code must be done to tailor the program to check what you want. E.g a period)

What checks are performed on in each CHK routine

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.

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.

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.

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 Amending/Reposting Journal Entries

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

Warning: Reposting journals that 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.

1. Client must de-allocate vouchers which need to be amended
2. NEOSYS support staff must wait for a day so that de-allocated vouchers are copied into Test database
3. Authorise required users to amend and repost (without record) in Test database only
   (While reposting, we have 2 options i.e. with record and without record. The 'with record' option causes the system to maintain a history of edits made. Hence, we want to repost without record so that there is no trace of the edit in the system)
4. Amend a substantial number of vouchers in Test and verify them.
   To verify if the edits made are reflected:
5. *Print all ledgers for the whole year
6. *Cross-check all balances
7. Once you verify the balances are correct in Test database, grant users permission to amend and repost in the Live database.
8. Ask users to amend and repost vouchers in the Live database.
9. Cross-check all balances for the current year.
10. If you successfully verify the balances, revoke permissions immediately. Else, wait for 24 hours and revoke permissions irrespectively.

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 ORIGINAL A/c No. of the Exchange Difference A/c.

F9, ESC to save and exit

REPOST

F5
REPOST XXX*YYYYY*ZZZ

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"

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.

Exodus

• Exodus TEST Database

1. /root/neosys/test <DBCODE>
2. After startup press "x" key.
3. Type: "chkalloc"

• Exodus LIVE Database

1. Stop all LIVE processes. (pressing x won't return prompt to enter check command if other LIVE processes running)
2. Run /root/neosys/run <DBCODE>
3. After startup press "x" key.
4. Type: "chkalloc"

Enter minimum period to start check from.

/root/hosts/test/work Command? chkalloc
Begin transaction
Making a new document/report 52360178.htm:
----------------------------------------
Minimum voucher year.period to check?
(0 for all)
201601

Enter 1 for all accounts. Enter 2 if you want to look at a specific a/c.

========================================
CHK.ALLOC
*1. All Vouchers/Accounts
 2. One Account`s Indexed Vouchers Only
 Please enter 1 - 2 or Enter to default or 0 to cancel.
? 1

Enter specific a/c no. or press Enter for all.

----------------------------------------
Which account do you want ?
Give the account number or name,
or press [Enter] if not known.
(separate multiple entries with spaces)
? 

Choose option 3 (Yes to all).

 REC*1:2*1 12/03/19 OPTI,A 2/   (Unposted) Voucher "REC*1:2*1" ln:2 missing from index "*OPTI*A"
========================================
Missing from O/I index
Add it? (5.4KB)
 1. Yes
*2. No
 3. Yes to all
 4. No to all
 5. Yes to all "*OPTI*A"
 6. No to all "OPTI"
 7. Skip all unposted vouchers
 Please enter 1 - 7 or Enter to default or 0 to cancel.
? 2

AREV

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.

For speed, omit old WIPxx and ACCxx ledgers since their accounts are probably all closed.

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

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

Check steps of each CHK program

Run CHK.ALLOC

Check the VOUCHERS file

Checks that allocations occur in pairs and that both sides refer to the same account number and are in the same financial period.

Checks not allocated more than the amount/base amount on the voucher.

Checks open items (not allocated or not fully allocated) exist in the open item records of the voucher index file.

Checks that allocations do not cause a rate change since automatic revaluation is supposed to occur on allocation.

Run CHK.CONTROLS

Checks the BALANCES file.

Check that the control account balances agree with the total of the balances of their subsidiary accounts.

Run CHK.VOUCHERS

Checks a lot of things in the VOUCHERS File.

Run CHK.BATCHES

Check the BATCHES file (Journals File).

Checks journal type, company code and currency codes are valid.

For each voucher check that it is not missing and that its voucher period, posted/unposted state and Journal No. agree with that of the Journal.

Checks amounts and base amounts are all numeric.

Checks base currency entries have matching base amount entries ie if base is USD then amount is 100USD and base is 100 (101 or something else).

For posted batches, checks A/c Nos. are valid.

Run CHK.VINDEX

Checks the VOUCHER.INDEX file.

For each entry in the index ie line on a ledger account.

Checks for ledger entries that have problems eg wrong account or missing voucher.

Checks A/c No, currency code, journal type and company code are valid.

Checks open items indexes are only for open item accounts.

Checks Journal type OB does not exist on movement indexes.

Checks that reversed batches have matching reversal batch and vice versa.

Checks vouchers exist.

Checks that the voucher period, date, currency and A/c No. agrees with the index.

Run CHK.OB

Check the BALANCES file.

Checks that opening balances are correct versus closing balances for accounts that are neither closed nor closing accounts.

Run CHK.BALANCES

Checks the BALANCES file.

Checks A/c No., currency code, voucher type and company code are all valid.

Checks balances are all numeric.

Checks the decimal places of balances of base currency are not more than the standard number of base currency decimal places.

Checks the base currency record references to all other currencies is alphabetical.

Checks all non-base currency balance records are referenced on the base currency record.

Run CHK.CHARTS

Checks the CHARTS and LEDGERS files.

Checks A/c and Original A/c are valid ie exist in ACCOUNTS file.

Checks any company and currency codes are valid.

Checks the internal lookup tables in DEFINITIONS file are correct.

Run CHK.ACCOUNTS

Checks the ACCOUNTS file.

Checks accounts exist in the Chart File.

Checks the account records representing Account and Orig A/c No. refer to each other symmetrically.

Checks that any Control A/c, Closing A/c, Company code and Currency code is valid and match the same in the Chart File.

Fixing opening balance of new year does not agree with the closing balance of the previous year

In order to fix this problem, redo the open new year procedure for the problematic year, where recreating opening balances (which is part of the opennewyear.subs program) should fix the issue.

Reopen New Year or Redo Open New Year procedure

You can reopen a year using the below command.

• Exodus TEST Database

1. /root/neosys/test <DBCODE>
2. Press x and then type reopenyear <Companycodes> YYYY
3. Press x and then run chkob. Include a few prior years as well to ensure all balances are fine.

• Exodus LIVE Database

1. Stop all LIVE processes. (pressing x won't return prompt to enter check command if other LIVE processes running)
2. Run /root/neosys/run <DBCODE>
3. Press x and then type reopenyear <Companycodes> YYYY
4. Press x and then run chkob. Include a few prior years as well to ensure all balances are fine.

• AREV

REOPENYEAR <Companycodes> YYYY 

   Media  Production  Finance  Management  Timesheets  Files  General  Exit
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒╒═══════════════════════════════════TCL - 2══════════════════════════════════╕▒
▒│                                                                            │▒
▒│ :REOPENYEAR A,AA 2020                                                      │▒
▒│                                                                            │▒
▒╘════════════════════════════════════════════════════════════════════════════╛▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒

In Maintenance mode, run CHK.OB and include a few prior years as well to ensure all balances are fine.

   Media  Production  Finance  Management  Timesheets  Files  General  Exit
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒╒═══════════════════════════════════TCL - 2══════════════════════════════════╕▒
▒│                                                                            │▒
▒│ :chk.ob                                                                    │▒
▒│                                                                            │▒
▒╘════════════════════════════════════════════════════════════════════════════╛▒
▒▒▒▒▒▒▒▒▒▒▒▒╔══════════════════════════════════════════════════════╗▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒║                   Years to check?                    ║▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒║ (0 or starting year for all, but only checks forward ║▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒║           ie ob v cb not backward cb v ob)           ║▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒║<15 16 17 18 19                                      >║▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒╚══════════════════════════════════════════════════════╝▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒