The Pristine General Ledger

I've worked with several accountants over the years and one thing I've noticed about them is that they generally like things neat and orderly. Unfortunately the real world is often messy and chaotic. Transactions get entered for the wrong accounts, quantities, or dates, which leads to reversal transactions, then yet another set of corrected transactions. Even with a flawless transaction record a company of even a moderate size can end up with thousands of general ledger entries that make finding the source transaction of any questionable trial balance number like looking for the proverbial needle in a haystack. Several features are being introduced in 3.6.0 to make life cleaner and more manageable for our accountants in the real world including a smarter G/L account search widget, the ability to modify erroneous general entries and a new optional Journal system.

General Ledger Account Cluster

At first glance the improved G/L account search widget is the most obvious change in 3.6. It includes the new auto-completer functionality found throughout the system, along with the ability to jump to and create or edit account numbers directly from the widget for those with privileges to do so. Unique to this particular type of search cluster is that these have been pre-set to search on the appropriate account types for their context. So, for example, if the expected account number in a particular context should either be an asset or liability account, then only account numbers for those types are listed on a search. That protective feature alone can help prevent errors in set up and ongoing business transactions. For those who are concerned about loss of flexibility, however, have no fear: You can still type in an account number for an "incorrect" type, and it will be accepted, but not before warning you of potential "unexpected" results!

Editing Posted Transactions

The next handy feature is the ability to modify posted Journal Entries. In the past we have considered the deletion and editing of any G/L transaction an absolute no-no, however this makes life hard in the real world where mistakes do happen. What we've done in 3.6 is introduce the notion of a "soft" delete of manually entered transaction types (Journal Entry and G/L Series). A soft delete means that the record is flagged as deleted in the database, disappears from most reports, and its amounts are removed from the trial balance... but the record still exists. This way you get the best of both worlds: the flexibility to "delete" unwanted transactions, but a complete audit trail remains of all activity. Deletions can be performed on qualifying transactions from the G/L series display:

The screenshot below demonstrates how you can still view "deleted" transactions by setting the option to do so on the G/L Transactions report. The drill down reveals that the transaction notes were automatically stamped with the name of the user and time of deletion.

Also note the other option you have of "editing" manual Journal Entries posted directly to the General Ledger. What happens when you do this is the original entries are marked as deleted, then copied into a new G/L Series which is opened into the G/L Series editing window. You can edit them however you like, then re-post. The edited series will have the same journal number as the previous, but the history of the original entries will still exist and be audit-able in the same way as deleted entries are. Again, if you liked the old unyielding behavior have no fear: the ability to delete and edit posted Journal Entries are privilege controlled. If you do not grant privileges for anyone to use these features (which is the default), then this behavior will not be allowed.

Journals

Finally, we have introduced the notion of new intermediate Journals  that contain transactional detail that supports the General Ledger (Not to be confused with the Journal Entry transaction type, which can be used whether this new Journal functionality is turned on or not).  Before 3.6 any kind of financial transaction created was posted directly to the General Ledger.  What Journals allow you to do is aggregate postings from all the detail into a summarized General Ledger posting thereby allowing you to potentially distill thousands of General Ledger transactions down to just a few. The posting of Journals can be done daily, monthly, or weekly. It is entirely up to the user how to implement it. To keep things simple for new users who may not understand this new layer of indirection use of the Journal is optional and by default it is turned off. You turn it on in Accounting > Setup > Configure > Accounting.

Note that once you turn it on and post transactions to the Journal it can not be turned off again until all Journals are posted to the General Ledger. When you turn on Journals you should give yourself appropriate privileges to use it (PostJournals and ViewJournals) and log out of and back into the system to make sure all new menu actions associated with Journals become available.

Once turned on all financial transactions are posted to Journals instead of the General Ledger.  Transactions recorded as Journals do not affect the trial balance until they are posted to the General Ledger. This is accomplished by a new utility in Accounting > General Ledger > Post Journals to Ledger.

As the screenshot indicates, you are initially presented with a summary of all unposted Journals. You can query on different date ranges if you only want to post on transactions in a specific time period. You can select one or all Source types, click post, and you're done. Of course we know that accountants being who they are will want to know A) what's going to happen when they post these things and B) where the numbers came from. To answer the first question you can click the "Preview Posting" option and re-query to see a summary of the transactions that will be posted to the G/L.

To find out where the numbers came from, you can right click and drill into the transactional detail behind these numbers. This right click drill down is also available from the G/L transactions window and the G/L Series window even after the Journals are posted.

One of the great things about the Journal feature is that not only does it do a nice job of consolidating things, but it gives you a chance to review and potentially reverse or correct any errant transactions before they muck up your General Ledger. But guess what? Even if some of these bad transactions make it through to the G/L, you can also perform the same soft deletion of  Journal postings as you can with Journal Entries posted directly to the G/L! If you do this, the Journal transactions are reverted back to their original state so you can make any necessary corrections and repost the set.

Finally, there's one other nice thing about Journals: You can distribute them on whatever date you wish. So if you ever have the problem of wanting to back or forward date transactions after the fact, Journal postings give you a flexible mechanism to do this.

As you can see, there is a lot of new and powerful convenience functionality here for accountants. Most amazingly, with these tools it is now possible for that obsessive compulsive accountant you know (or are) to manage a completely clean and pristine General Ledger even when all the world around you is doing their best to make a big mess!