OCD IN VISUAL ERP

Do you have things that drive you crazy? Maybe it is:

• scratching nails on a chalkboard, or
• people not returning your calls or texts, or
• REPLYING TO EMAILS ALL IN CAPS, or
• the list could go on …

One of my cohorts recently blamed things like this on his OCD.  

Well, I have one in Visual ERP that usually sets me into a tailspin. It is when 1 General Ledger account is used in the GL interface table for posting unrelated, incorrect, or missing data. Here’s some examples of these types of postings:

1. Missing product codes on parts in part maintenance will post to the default Inventory Account from the GL interface table. Let’s assume a company decides to use account 17777 as the account. Someone sets up a part and forgets the Product Code and sure enough it posts to account 17777.  
2. A sale is made with no product code and thus posts to default sales, again, in this case it is account 17777. Here’s the source of the problem. A customer order is created with no product code. Sure enough, it posts to account 17777.
3. There is labour charged to a work order, but the resource doesn’t have either an applied burden or applied labour account. This would post to account 17777.
4. I could go on and on …

But you might be getting the idea that the account 17777 could contain a myriad of problems.

Now let’s take a step back. It is month-end and your month-end procedure states- ensure account 17777 has a zero balance. Your process is drill down on the account, then determine the journal type. Then drill down to the exact transaction or transactions to determine the cause. In some cases, you can fix the transaction at the source and in other cases you may opt to create a General Journal to remove the dollars (creating unnecessary General Journal entries in Visual ERP is one other thing that drives my OCD crazy but that is for another day).

Now, I want you to imagine. Instead of 2 batches there are 10 or even 15. Oh, yeah and each one can get a posting from a different journal type. So here you are at month-end, under the gun to get your reports done and you have to play detective to determine where the items should have posted. I don’t know about you, but I want an Easy and Fast button, especially at month-end.

What can you do to overcome this? Here is my preferred approach. Let’s set up a few more accounts so that there is only 1 posting type in 1 account. When setting up the account, also, let’s do 2 things:

1. Give an account description that is meaningful. The account description could be ‘Inventory – No product code’ which explains exactly why this would have a posting or ‘Sales – No Product Code’ or ‘Applied Labour/Burden – No GL Account’. 
2. Set up the account in the appropriate section of your financial statements so if you don’t fix it during month-end it summarizes in the correct financial statement presentation. With the account Inventory No Product Code account, summarize this to a parent account related to inventory. If not fixed, it shows under inventory.

I recently came across such a scenario. The inventory was posting to an expense account instead of an asset account. In this case, the profit was understated as the purchase went to the expense. To top it off the balance was not fixed at month-end. I have to admit my OCD was going off the charts on this one.

You may be going into Visual right now to see how your GL interface is set up. It is under Ledger, Application Global, just in case you want to look. Scan down the list. Do you have 1 account that appears in multiple places? Do these accounts seem like a similar transaction type? If these are unrelated then you may have been struggling with the situation.

Please do not jump into setting up new accounts and changing the GL interface table immediately. There are a few things you need to know first.

1. Some transactions will take effect with new transactions only so these are safe to change. The general rule is, if the transactions are related to General Accounting (AR, AP, etc.), these accounts will be used for any new transactions so you should be safe changing the GL interface table. Just thinking about doing this makes me calmer. My OCD is getting parked.

2. Some transactions can correct (reverse) the posting if the source of the problem is corrected, and the transaction is triggered to post again. I like to explain that Visual ERP has a memory like an elephant when posting manufacturing transactions. Let’s continue with the example of parts with no product code to explain further. The fix would be:

1. Assign the product code to the part. (Either Tenant or Site level)
2. Go to the transaction type (PO, CO, WO or adjustments) through Costing tools (admin menu) and select the order or transaction and set the Posting Candidate to Yes. This will tell Visual ERP to relook at the transactions and repost based on new information. Visual will post the amounts to the new accounts and reverse them from the previous account (say 17777).

This type of fix would be required for transactions impacting Inventory, Work In Process, Applied Labour & Burden and possibly Cost of Sales. 

Whenever I am doing “clean up” activity in Visual ERP, I like to post everything, then make the fixes and post these fixes all in 1 big batch. Actually, if you want to do these types of fixes, DO IN A COPY OF YOUR DATABASE FIRST. I know. I am yelling but I want you to know what impact this will have on your database and how much time costing will take to do these changes. For the full details on how to make fixes in Visual, click the attached link for the download.  Click HERE

3. Some entries in postings could have different impacts based on the Dr. versus Cr. side of the entry. Think Cost of Sales. This entry will Dr. COGS and Cr. Inventory. In this case the Dr. to COGS would not change (unless the GL interface for COGS is changed) as Visual is looking at the product code on the customer order. However, the credit to inventory would change as it is looking at the updated product code on the part.

There are different rules depending on the account and the posting type. I have put together a chart to explain how the many accounts work and how to fix when they share the 1 posting account (17777).

Feel free to go to Click HERE to download a document telling you about the GL Interface table.  

Also, I would like to thank TA for the inspiration for the blog. Your struggle with this account resulted in my idea. But I am happy you found the cause of the problem so it should not be an issue any longer. Now we just need to change 1 line in the GL interface to eliminate the need for any GJE’s thus eliminating one of my other pet peeves.

Do you have any questions related to Visual, especially financials? I encourage you to review our blog history for ideas or feel free to contact us to see if you could be our inspiration for our next blog.