Microsoft Dynamics GP 2010 : Preventing posting errors by managing Batch dates

1. In Dynamics GP select Administration from the Navigation Pane. Select Posting under the Posting heading in the Setup section on the Administration Area Page.

2. Select the Series to change the settings for. For our example, select Purchasing.

3. Select a posting Origin. In this example, select Payables Trx Entry to control posting settings for accounts payable voucher entry:

4. Deselect the Allow Transaction Posting checkbox to force posting to the general ledger by batch.

5. Select the Transaction radio button under Create a Journal Entry Per to avoid rolling up transactions in the general ledger.

Sending batches of subledger transactions to the general ledger as a single transaction has its roots in ledger paper accounting. This practice moved to software when disk space was at a premium. It is almost never needed now and complicates tracing subledger transactions through the general ledger.

6. Click on Save, then on OK to finish.

1. Select Purchasing from the Navigation Pane. Select Batches under the Transactions section on the Purchasing Area Page.

2. Name the batch with your initials followed by that day's date. My example batch is named MDP-2010-02-17:

• By naming batches this way users searching for a batch will see the available batches sorted in order by user initials and then date.

  • Typically, firms either let users post their own batches or they use a designated individual/group to post batches from multiple users:

    • If users post their own batches, start the batch name with your initials followed by the date such as MDP-2010-02-17. This will cluster a user's batches together when posting, making it easier to post multiple batches for a single user.

    • If a different individual posts transactions for multiple users, start the batch name with the date followed by the initials such as 2010-02-17-MDP. This clusters batches together by date making it easier to select the right batches across multiple users.

  • Dates in batch names should start with the year and then the period such as 2010-02. This naming convention clusters batches together when approaching year end or period end. For example, it's typical at period end to have some left over transactions from the previous period and new transactions for the current period. Starting dates with the year and period helps ensure that users select the correct batch to post.

  • Single-digit periods and days should use a zero in front as Dynamics GP sees batch names as text. Not using a leading zero will cause a batch for period 10 to come before a batch for period 9.

3. Select Payables Trx Entry in the Origin field.

4. Set Frequency to Single Use for our example. Recurring batches have a frequency other than single use (monthly, weekly, and so on). They are designed to be posted multiple times. For recurring batches, the following recommendations apply:

• Start recurring batches with the letter 'z' to cluster them at the bottom of lookup windows. It may make sense to date recurring batches with their end date instead of creation date to make it easy to identify when this batch will stop recurring.

• Provide a complete description and notes for recurring batches since the rational for the recurring batch may fade from memory over time.

• If there are multiple transactions in a recurring batch ensure that they are all designed to stop repeating at the same time.

5. Enter the Posting Date for the batch following these recommendations:

• One period per batch: Users shouldn't mix transactions from multiple periods in a single batch. This makes it impossible to post the transactions in the proper period since the entire batch will post in one period.

  The only exception to this is the general ledger (GL) batches. General ledger batches always use the date on the transaction for posting. There is no option to post GL batches by date.

• Post using the batch date: Posting using the batch date ensures that all of the transactions in the batch post using the same date and the date is visible with a glance at the batch. This contrasts with individual posting where the posting data could be different on each transaction.

  For transaction posting the true posting date is hidden behind an expansion arrow on the date field making it difficult to validate the posting date on multiple transactions.

6. Click on the Transactions button to add transactions to a batch.

7. Once transactions are entered batches can be posted from the same window. When posting batches:

• Non-recurring batches should disappear when posted. In the event that this doesn't happen users need to select the printer icon in the upper right to print the batch edit list either to paper or to the screen. Printing the batch edit list prior to posting is a best practice but this process can be impractical for batches with a large number of transactions.

• The Transaction Edit List will show batch-level errors at the top and transaction-level errors below any problem transactions. The most common batch-level error is a closed fiscal period preventing batches from posting. For transaction-level errors missing accounts or account related problems are seen most often.

• Batches that contain errors may fail posting and end up in Batch Recovery. The Batch Recovery window is found in the Administration Area Page under Routines. Batch Recovery will either resolve minor errors and continue the posting or return the batch to a state where a Transaction Edit List can be printed and reviewed for corrections: