Troubleshooting NEOSYS Finance System

Cross Check Balance errors

Error Message

This is a sample Cross Check Balance error message:

Server=NEOSYS-SERVER
Database=1D68EE63
Client=99_99_99_9
User=NEOSYS
Process=4
Request=LEDGERPRINT
Message=
Cross check balance error:

Ledger:TD A/c:STAR Type:Open Item
Ledger:TD A/c:STAR Type:Open Item
NEOSYS Ver:22:13:59  03 JAN 2007
@Id=
Data=STAR^^^^^^^^^1/06-12/06:SR:FZ:1;3:AED:12/2006-12/2006:12:AED:::::::1:2^^^^^^1

Error Explained

Whenever NEOSYS prints a ledger account or statement it can add up all the transactions onto the opening balance and derive the closing balance itself i.e. o/b + trans = c/b and naturally the c/b SHOULD agree with the c/b according to the balance on the account balances file unless something has gone wrong in the updates of the files.

Hence cross check balance can never really occur by user error and usually would be due to defect in the hardware or software and now since servers rarely fail, the cause is nearly always in the software.

Solution

First refer to Fixing Cross Check Balance Error and thereafter escalate to the programmer if still not fixed.

How to check for Cross Check Balance errors on all accounts

1. Goto Finance>Ledgers>Ledger Account
2. Change settings to desired company, year and currency
3. Select multiple ledgers to display.

Note that there is a 10 minute request time out, so do not select all the ledgers/accounts in one go.

Resolving opening balances in P&L accounts

Resolving opening balances in P&L accounts where you fail to put a closing account on them

Cause

If the P&L chart is a section of the top level "GL" chart and not represented as a subsidiary "PL" chart then failing to add the closing a/c when creating a new P&L a/c is an easy mistake to make since it must be done for each P&L a/c one by one. If the closing a/c is not setup before the Open New Year procedure is run, it results in the presence of opening balances for the P&L a/cs for the next year.

For example, if the closing account (eg: a/c 792 or 88) of a P&L account is not specified (i.e. in each account line) then NEOSYS will merely carry forward the closing balance of the account to be the opening balance of the new year.

By contrast, when the P&L a/cs are held in a subsidiary chart then it is possible to set it up (by assigning the closing account in the header of the chart) so that all a/cs in the subsidiary chart are closed. In this case, any new P&L a/cs are automatically closed (i.e. there is no need to specify the closing account on each P&L account line.) - so the problem does not arise.

Solution

To solve this, use Opening Balance Journals to transfer the balances to the closing a/c (that was supposed to receive the balances in the first place) by creating a journal into any financial period and date of the new year. The exact period and date are not important since Opening Balance Journals, although like normal journals in other respects, do *not* show as entries on the ledger account, but instead amend the opening balances of the financial year of the ledger account.

Credit (or debit) the problematic P&L a/c by the amount of its opening balance and debit (or credit) the "Profit and Loss Brought Forward" a/c or whatever closing a/c the account should be closed to on an annual basis.

Don’t forget to add the closing a/c to the chart otherwise the same problem will arise again next year. Opening Balance Journals should be done by finance staff not user support staff so that the auditors see the correct records.

If you are trying to fix the closing balances over the last few years, remember that you need to do one opening balance each for every past year. Example: if you have an opening balance issue since 2008 (i.e. 2007 balance of some accounts are showing as opening balance in 2008) and 2009 (i.e. 2008 balance of some accounts are showing as opening balance in 2009) then you need to two OBJ, one each for 1/2008 and 1/2009.

Permanent Solution

Ensure that the closing account of the offending account(s) are set correctly otherwise the problem will reoccur every year.

Correcting mistakes in postings

Posted entries cannot be modified except by NEOSYS under certain circumstances.

NEOSYS has a policy not to do corrections to postings except in special circumstances.

1. Corrections to opening balances and opening items since those are a once off issue.
2. Amendments requested by top management for exceptional adjustment of accounts that cannot be handled in any other way
3. Vouchers are missing from posted batches. See Missing vouchers in posted batches

General errors in postings such as the financial period, account number and amounts must be corrected by reversal and correct journals.

The repercussions of granting permission to edit/report journals would be as follows:

1. NEOSYS Financial Module can no longer be trusted if postings are subject to modification
2. It is not common practice to do such manipulations
3. It can lead to possible errors in numbers
4. Staff can become complacent and careless while posting entries and frequently ask for this permission

So, restricting users from editing/reposting journal entries promotes a more healthy and vigilant working environment where users verify each journal entry before posting it which effectively leads to good accounting practices.

The NEOSYS software for reposting journals appears to but does NOT work for posting which have already been allocated. It creates cross check balance errors in the open item accounts. To avoid this, any allocations can be de-allocated ESPECIALLY when the account number is being changed or the amount is being reduced or the currency changed.

The following information can be changed by authorised users even after posting. In the Voucher File and therefore on the detail ledger account/statement: Date, Due Date, Despatch Date, Reference, Details, Analysis Code and allocation. See What can I change in the finance voucher after posting?. Unfortunately the journal printout is unchanged by any amendments and remains as it was entered.

You Cannot Post 0 Currency Amounts to Open Item Accounts

While trying to post journal entries in NEOSYS, you may come across the following errors:

ERROR MESSAGE:

CANNOT SAVE "P IN 552 U" because:
You cannot post 0USD to open items account like UM7R
unless the base amount is also zero
because it cannot be allocated later
(in line 1)

ERROR MESSAGE:

CANNOT SAVE "1 INV 664 U" because:
Sorry, you are not authorized to do
Journal Post Revaluation
You cannot post -0SYP to open item accounts like SCH3294
unless the base amount is also zero
because it cannot be allocated later
(in line 3)

As the messages say, you cannot post zero currency amounts to open item accounts unless the base amount is also zero because it cannot be allocated later.

In order to understand this issue, observe that having a outstanding item of zero amount on an open item account (in any currency) logically means that the outstanding base equivalent of that outstanding item should be zero too.

Logically, all items posted to open item accounts need to be eventually allocated to other items in order to remove them from the list of outstanding items for the account. However the NEOSYS allocation process only allows allocation of real currency amounts since it ensures that the equivalent base amounts are proportionate to the currency amounts and automatically makes entries to the exchange gains and losses accounts to reflect this.

Having a base amount outstanding when the currency amount outstanding is clearly not correct in the final analysis and NEOSYS is currently programmed to prevent journals like this from being manually entered.

Cause

The situation can arise due journal entries generated by NEOSYS when the exchange rate is adjusted after invoicing and a debit or credit note is issued to account for the difference. In this case the currency amount to be posted in finance is zero while the base amount is not zero.

Solution

1. Open the appropriate journal
2. Change the account of the offending lines to the exchange gain/loss account.
   • The exchange gain/loss account is not an open item account and hence it will accept “zero amount, base currency only journals”, otherwise known as revaluation journals.
3. Post the entry

Alternative Solution

1. Ask NEOSYS programmers to temporarily patch the software to allow the posting. If this situation turns out to be a recurring event then NEOSYS software will be patched to allow authorised finance users to post this type of transaction without involving NEOSYS programmers.
2. Post the entries
3. Run the NEOSYS revaluation program on the account to transfer the balance to the exchange gains and losses account. IF YOU ARE NOT SKILLED AT REVALUATION DO THIS ON TESTDATA FIRST!

Note - NEOSYS software versions from Feb 2012 generate journals automatically with exchange gain/loss account where appropriate.

Solving Error: Index overflow - run Finance, Maintenance, "Clear Open Items"

Cause

For low and medium volume of transaction this only occurs after many years of using NEOSYS. In this case the only possible problem is that ledger and statements of accounts of open items "as at" ancient periods will be missing items.

For high volume accounts this occurs when the Clear Open Item procedure is not performed regularly. In this case, older unallocated items may be missing from ledger accounts/statements causing "cross check balances" which have to be dealt with by technical support using CHK.ALLOC.

For more information see the Clear Open Item screen and, if and when it becomes available, documentation for why, when and how the "Clear Open Items" procedure must be run.

Solution

Perform a normal "Clear Open Items" procedure in the Finance, Maintenance Menu. (NB normal web interface - NOT Maintenance Mode)

Why does an outstanding not appear while taking a ledger printout

Check if there is a CCB error for this account. If so follow instructions to fix CCB error

If there are no errors check the voucher index size. Large voucher index size could the outstandings is not appearing in ledger printout.

If the voucher index is high then clear open items and check if the outstandings appear.

Proactive Checking if Clear Open Items needs to be performed

To find out which accounts are more than 50% "full", in maintenance mode press F5 and type the following command

LIST VOUCHER.INDEX SIZE WITH SIZE > 32000

The maximum size is around 65500.

Converting Balance Forward Accounts to Open Item

Problem explained

Users cannot change the type of a chart of accounts from Balance Forward Account to Open Item after any postings have been made, but it is possible in maintenance mode IF AND ONLY IF the users are prepared to see EVERY ITEM EVER POSTED ON EVERY ACCOUNT IN THE CHART AS OUTSTANDING.

NEOSYS has no way to match and allocate the old items to each other automatically so, after conversion, this MUST be done manually and can be time consuming and EFFECTIVELY IMPOSSIBLE for chart of accounts with many account or large accounts. In this case the ONLY solution is to create a new chart of accounts (with the same control account) and start from scratch with new accounts perhaps transferring the balance of the old accounts to the new accounts.

Solution

The solution involves editing the LEDGER and CHARTS file (in Maintenance mode) to change the type, saving the chart once again, and then running F5 CHK.ALLOC to add items missing from open item indexed.

After this the account will be an Open Item account and all items will show as outstanding. One easy way to knock off these items is to find out the balance of this account (eg. 45000 AED) and then pass a Journal into the account to allocate and clear all the old items and that journal itself would be the open item of the new account i.e. +45000 DR -45000 CR

Resolving the "NONE supplier does not exist" message on invoice postings

When posting an automated invoice journal from NEOSYS you may encounter a message which which says "Cannot save XXXX because NONE supplier does not exist". The error message will look something like this

Error Message:
Cannot save "1 INP 18 U" because:
CONTRA A/C "28*1*MIRAO**UAE*NONE*PPP" ANALYSIS CODE IS INVALID
FIELD 6 - "NONE" SUPPLIER CODE DOES NOT EXIST
(in Line 1)

This error appears because there was no cost related to this invoice and as such for billing analysis NEOSYS takes the supplier code as NONE in the billing analysis code. To avoid this message create a supplier code NONE in the supplier file (the supplier name is irrelevant and could be NONE aswell) and then post this invoice. This is a one time setup per client.

Problem: Batches “missing” from selected periods

NEOSYS allows you to clear the default batch period during data entry. Then the posting period is determined by the voucher date and there may be different periods posted within a single batch.

Such batches are listed in period 0 and not in the period of any specific voucher in the batch. This applies even if all the vouchers in the batch happen to be in the same period.

Problem: Account number does not exist

User can find this message while passing/positing any entry in finance.

Explanation:

This error means that the account for which a user is trying to post an entry does not exist in finance ledgers.

NEOSYS allows users to put the accounts manually in their respective chart but all the provision/accrual accounts are automatically created in their respective chart. There can be a scenario in which the accrual accounts are not created automatically as explained below:

Problem:

Clients who are using an older version of neosys and have entered a schedule number which begins with a non-numeric character, face a problem that accrual accounts are not automated and receive the message "Account number does not exist" while posting an supplier invoice before creating an Invoice to client.

Troubleshoot this message:

• All accrual accounts are created in ACC20XX ledger after the schedule is approved. So check if the schedule is approved, if not ask user to approve the schedule.

Solution:

• This problem was fixed in 04th July 2011 version of neosys. So first step is to upgrade a client database. Upgrade will prevent in causing the problem again for future schedules.

• Now the solution to this problem is to save the schedule again without doing any changes/amendment on a schedule. This can be done by changing something and changing it back before saving.

Solving ALLOCATION EXCEEDS BASE AMOUNT error

This message may come when running the CHK.ALLOC maintenance procedure.

Under normal circumstances, the total amount and base amount allocated to other vouchers cannot exceed the amount and base amount on the voucher. In other words, you cannot allocate a payment of 1000 to invoices totaling 1100. However the situation can arise in some circumstances on currency amounts that have been revalued. If you cancel manual allocations on currency amounts and there have been some revaluations (since the original manual allocation) that resulted in an INCREASE in the amount outstanding.

Solution: Run the revaluation program since its job is to amend outstanding base amount to agree with the outstanding currency amount at the prevailing exchange rate.

Locating and correcting Exchange Gain/Loss A/c errors

Client: Can you please check the account 982 exchange difference it shows a credit balance of 14mn in Nov only

Steve: and?

Client: how can there be 14mn exchange difference

Steve: defective data entry

Client: didnt get? what does that mean

Steve: incorrect data entry by your staff

Client: how to find what is wrong in that

Steve: lol

Client: why?

Steve: accounting 101 ... print the account and find the incorrect transactions? I am your programmer ... not your accountant :-)

Client: these are the Invoices rasied in USD thats all i know

Steve: if you can find defective transactions, I can help

Client: there cannot be any wrong accounting by media people as they can only raise Invoicxe the entry in exch diff a/c says its RV these are auto entries passed by system

Steve: please just point me to any wrong transaction ...

Client: there is an entry thru RV11/54 credit of 4.4 mn in exch diff a/c

Steve: which company?

Client: i

Steve: can you check the voucher that made this entry? what is the other side?

Client: INV-110433

Steve: can you check all the other base conversions on that invoice? probably the exchange rate rate used was totally wrong yup

Client: ya i see 1:1 is used for USD to AED

Steve: anything to do with iraq ....

Client: ya