In our
last post, we saw how the
Balance Sheet, the
Income Statement and the
Statement of Changes in Equity are prepared and shown to us by the application.
To complete the work, we have to cover another little but important detail: automation.
As you might have noticed, there is a problem when we want to prepare the Financial Statement at the end of a period (say, at the end of the month), because there is a "difference yet unexplained" showing up before we close
Income Summary to
Retained Earnings and
Dividends to
Retained Earnings. The application takes into account what has been recorded in the journal, so, before these entries, there is no way to have the correct data.
But we don't want to actually write such journal entries at the end of each month, do we?
The solution lies in preparing some templates for the journal entries, and mark them to be automatically executed each time the statements are prepared.
A template is a place where we can define how a journal entry is made. If we frequently sell services of some kind, for instance, instead of choosing each time the accounts to use, we just prepare a template for the entry.
First, let's prepare a fictious entry, as usual, but instead of clicking the "Save" button we click on the "Create Template" link:
We will be taken to a page where we can fine-tune the template:
For each account, we can choose one of the following options:
- ask, if we want the amount to be asked when we prepare the entry;
- close, if we want the amount to be computed so that the account balance goes to zero;
- balance anyway, if we want the amount to be always computed so that the entry's debits and credits balance automatically;
- balance on match, if we want the amount to be computed so that the entry's debits and credits balance, but only if the resulting amount matches the ordinary outstanding balance for that account.
For templates that are to be used manually, we'll probably want to use always
ask or
close. There is also an option to set if we want this template to be used automatically. We'll discuss that later.
When we use a template manually, we are presented the accounts to be used, with the boxes for debits and credits highlighted:
This saves us the need of selecting the accounts and remember where to put our numbers. Helpful, isn't it?
The powerful thing comes when we check the "Apply this template automatically" box. Let's prepare two templates for the last entries of the month.
In the first one, we want
Income Summary to be closed, and
Retained Earnings to be balanced to, but only if the amount is a credit (and we want the comment "Net Income" to improve how the Statement of Changes in Equity looks like):
This automatic entry will fail if we have a net loss for the month (we can choose
balance anyway to avoid that this happens).
In the second one, we want
Dividends Declared to be closed, and
Retained Earnings to be balanced to, unconditionally:
The list of our templates should look like the following:
We can set each template to be automatically applied or not, and we can delete it to make a new one, if we want.
What are the benefits of these automatically-applied templates? If we don't have the last journal entries in our journal, the application knows how to compute all the needed data anyway. Let's check. From our previous example, let's remove the last three entries (concerning income summary, retained earnings and dividends), and let's have a look at our Financial Statement. It will look exactly as the one that we prepared last time, with some magic going on behind the scenes.
If we are curious, or if we need to debug our templates, we can have ask the application to show us the automatically-generated entries:
We will be presented the list of the entries coming from the automatic closing of accounts from the
Income Statement and from the templates that we marked as automatic:
Entries that fail are shown as striked over, to let us understand what worked or didn't work. If we look at the journal, we won't find any trace of that. (Why? Technically these insertions are made during a database transaction that is
rolled back, to the previous state, at the end.)
