Inconsistency in Consolidations

Greetings, Our customer is on Canadian v2.60 with all improvements. We are trying to set up Consolidations for this customer. Our implementor has spent many hours already setting this up, and so far it works… almost. We can Consolidate the two foreign currency companies to the Consolidation company, but as soon as we try to Consolidate the LCY company, we get the wonderful CONSISTENT error message. Just curious if anyone has seen this error message in this scenario. Many thanks!

I think you have problem with Debit and Credit amounts in GL transactions. I would recommend creating Total G/L Account that sum all Posting accounts and Add Debit Amount and Credit Amount to the Chart of Accounts Form. Debit Amount should be equal Credit Amount. (Normally it is, but sometimes people try to change Amount Field manually but forget about Debit and Credit amounts).

quote:


Originally posted by Kristopher
Just curious if anyone has seen this error message in this scenario.


Hi Kristopher, Back to the nature! That is a very well known problem which almost appears everytime while consolidating from companies which have foreign currencies. As I can remember, we have this problem since version 2.01. During the import, either from the database direcr or from a file, all the values are calcualted to the LCY using the given exchange rate. And here is the problem with the rounding. As the consolidation is direct posting this values, for more than 80% of all calculations we will have a rounding difference which will give the inconsistency error. You have to accumulate the rounding differences during the import and post one more line at the end of the consolidation. That should not be to difficult as the consulidation code itself is not that complicated. Regards Walter

Walter: Unfortunately, our issue is not with the foreign currency companies. The issue only occurs when we try to bring over the local currency company. However, one thing that the Implementor is saying is this makes sense in terms of currency rounding. Could you give us more detail about how one would accumulate the rounding differences during the import? Valentin: The Implementor said this sounds possible, and would like more details about your method as well. Thanks all!

You could also have problems with closing dates. It was some years ago now, but i remember that there was some problem regarding to how the consolidation functions treated closing dates. //Lars

Hi Kristopher, G/L Account table has fields “Debit Amount” and “Credit Amount”. You have to make these fields visible in the Chart of Account Window. (Design the window and add the columns). Then you should create Account with type total and in totalling field enter whole range of Accounts. (00000…99999 or smth like this depending on numbering of accounts). System will calculate “Debit Amount” and “Credit Amount” fields. “Debit Amount” must be equal “Credit Amount”. If it is not you will have “Inconsistent” error.

Maybe this sounds a bit stupid… but sometimes it happens that the unit amount rounding precision and the invoice rounding precision are not properly setup on the general ledger setup (sometimes when creating the company someone forgets to put that…). If it’s not properly setup, the difference caused on the different roundings could also give you the inconsistent error. Regards,

quote:


Originally posted by apertierra
Maybe this sounds a bit stupid… but sometimes it happens that the unit amount rounding precision and the invoice rounding precision are not properly setup on the general ledger setup (sometimes when creating the company someone forgets to put that…). If it’s not properly setup, the difference caused on the different roundings could also give you the inconsistent error. Regards,


Thanks for this tidbit. I think we’ve double checked all the Rounding Precision fields. We noticed this to when we’ve seen other instances of customers getting the CONSISTENT message. My Implementor is pretty good about such things. But always a good thing for people to check! Also note that databases that get upgraded sometimes need these fields set. Example is our one customer that upgraded from Avista and these fields were of course new to the whole database. Cheers!