Working with Recurring Batches in Dynamics GP 2010
Most finance departments have at least a handful of journal entries they need to make on a regular basis, whether for accruals or allocations or other reclass entries. We could definitely do this longhand each month, entering each journal entry manually. But with the use of recurring batches, we can simplify the process—and hopefully speed up your month-end!
Let’s start with the batch setup: Financials Page | Transactions | Batches
The key to setting up a recurring batch is the frequency. This defaults to single use, which is used for most journal entries. A single-use batch is posted once, and the transactions are no longer available in Work (unposted status). If you pick another frequency, like monthly, the batch automatically becomes a recurring batch. You can save entries to the batch.
For recurring batches, there are five additional important fields:
- Clear Recurring Amounts – This option will clear the amounts in the entry window when the batch is posted. You then can enter updated amounts before posting the batch the next time.
- Last Date Posted – This will track the last time you posted the recurring batch.
- Times Posted – This will track the total number of times you have posted the batch.
- Recurring Posting – Select this option if you want the batch to be posted only a certain number of times—perhaps a recurring batch is only valid for 12 months, so there would be 12 postings. Note: When the recurring postings are reached, the entries will post the final time and not recur.
- Days to Increment – This field is available if the frequency selected is miscellaneous. This can be used if you need to increment the recurring batch in a nonstandard way—for example, every 15 days.
Once you have your batch configured, you can enter transactions as you would normally at Financial Page | Transactions | General.
Then, when we post the batch (Financial Page | Transactions | Series Post or Batches) it behaves as it would normally. The posting journals will print as they would normally. The difference is that rather than the batch going away, as it does with a single use batch, the batch remains available after posting in the Series Post and Batch Entry windows:
After posting the batch, it’s still available. Note that the last date posted and times posted have been populated. In this case, prior to the initial posting, we marked “Clear Recurring Amounts.” So let’s look at the effect on the actual entry.
Financial Page | Transactions | General
Note two key changes:
- The transaction date has been incremented based on the batch frequency to May 30, 2017—monthly from the original date, April 30, 2017.
- The debit/credit amounts have been cleared because we marked “Clear Recurring Amounts” when we created the batch. This must be marked before you post for the clearing to occur.
We could populate the amounts and/or edit the journal entry as we would normally. Then, at the end of May, we could post the batch again. Because the batch remains available throughout the month, it’s important that you name the Batch ID something obvious so users know it is a recurring entry, e.g., MONTHLY or Z_MONTHLY or Z_ALLOCATIONS; naming with a Z ensures the batch falls to the bottom of the batch lookup. Naming the recurring batches in an obvious way will help to avoid accidental posting of the batch. If future periods are open, the recurring batch could be posted multiple times into the future.
Another important note about recurring batches: Note that the journal entry number of the original entry dated April 30, 2017, and the recurring entry for May 30, 2017, both use journal entry number 3543. Recurring entries will use the same journal entry number each month. This is unique to recurring entries, as GP does not generally allow duplicate journal entry numbers within an open year; this is done on purpose so we can track and identify all entries resulting from a recurrence.