Utility | Check GL Inconsistencies in Business Central

What do you do when you’re customizing processes that affect one of the most important tables in BC, the G/L Entry table, and you run into the dared CONSISTENT function error? ☠️

(Go straight to Solution!)

Customizing processes that touch the G/L Entry table is nothing new to Business Central, and a few specialized ISVs (or even Custom Extensions) also go through the same processes. Developers writing such extesions, more often than not, run at least once into this very known Consistent error message:

How to recover from this?

Original Solution from back in the days…

Years and years ago, developers had the same issue, and I’m not sure exactly who came up with this solution, but I have some hints that this might have been the original post in good old Mibuso Forum.

User ara3n suggested the following: To catch the CONSISTENT Error, we should create a Single Instance Codeunit that will keep a Temporary table with G/L Entries. The first time this Codeunit runs, it will enable the “tracking” of G/L Entries. The second time it runs, it will show all the G/L Entries that have been “tracked” so far.

He modified the base code on Codeunit 12 - Gen. Jnl.-Post Line, so that if “tracking” was enabled, for every G/L Entry that NAV would insert, a duplicate entry would be recorded in the temporary G/L Entry table kept on the Single Instance CU. With this, it was possible to intercept any records being inserted in the G/L Entry table using standard NAV Posting Codeunits.

If users ran into a CONSISTENT function error message, even though their original transaction was rolled back, the records in the temporary record were not. So, in order to try to detect which G/L entries were faulty, users would:

  • Run the Single Instance CU, from the Object Designer, to enable “tracking”
  • Run the posting process with issues
  • Run into the CONSISTENT function error message
  • Run the Single Instance CU again to view the “faulty” G/L Entries

With this, it was pretty easy to detect what entries had the wrong amounts in it, or, if a full leg was missing from the balances.

BC Repositories Solution

With BC’s architecture using Event Subscribers, the actual implementation becase a lot easier. I still created a Single Instace Codeunit for the same two original reasons:

  • Set Tracking on or off
  • Keep the temporary G/L Entry records

Then, all I needed to do in terms of intercepting CONSISTENT issues, I just subscribed to the OnAfterFinishPosting event on Gen. Jnl.-Post Line codeunit. The signature for this event is as follows:

1
local procedure "Gen. Jnl.-Post Line_OnAfterFinishPosting"(var GlobalGLEntry: Record "G/L Entry"; var GLRegister: Record "G/L Register"; var IsTransactionConsistent: Boolean; var GenJournalLine: Record "Gen. Journal Line")

Among others, we are focused only on the following parameters:

  • GlobalGLEntry: a copy of the G/L Entry table with the new records
  • GLRegister: a copy of the G/L Register table with the new records
  • IsTransactionConsistent: a boolean indicating if the G/L Entry table is balanced or not

With these parameters available, the only task left is to check if IsTransactionConsistent is false or not, and then store the faulty G/L Entry records, if the single instance codeunit is set to track consistency issues.

How to Use this Utility

From the BC Repo - Utilities page, search for utility “Check G/L Inconsistencies” from the list, and hit action Launch. You will be presented with the following page:


BC Repo - Utilities page

  • Hit Start Tracking if you would like to start recording faulty transactions
  • Hit Stop Tracking if you already finished your analysis. Note: Tracking will be automatically disabled once your web session dies.
  • Hit Refresh Entries if you recorded transactions already and they’re not showing on the page yet.

Use the fields at the bottom of the page to detect if Tracking is enabled or not, as well as to check if the Balances are correct. Most likely, Total Debits and Total Credits will not be matching, and from the G/L Entries, you shall find the reason for the unbalance.

Out of Box Inconsistency Reports

In the past, both VAT calculations and Currency Exchange calculations were prone to triggering the CONSISTENT function error. To this date, it still happens under a few situations, and that’s mostly due to rounding issues more than anything.

I don’t usually run these 2 tasks, but from what I read in the BC source code, there is a function ShowInconsistentEntries open_in_new that is used by both Adjust Exchange Rates (Report open_in_new and Codeunit open_in_new) and Calc. and Post VAT Settlement open_in_new processes.


That’s it! 🎉

If you liked this BC Repo Utility, this development, or if you have questions or comments about this, don’t hesitate to react and/or post on the discussion below (you will need a GitHub account).

Disclaimer

If you use this BC Repo Utility, please use it at your own risk. Truthfully there’s not a lot of risk here but you have to be mindful of any potential conflicts with other existing extensions in your environment. Also, don’t forget to always try these features in a Sandbox environment first, and have users test it before really deploying to Production.