Understanding Microsoft Dynamics GP module integration : Best practices for posting setups

Navigating through the posting process in Microsoft Dynamics GP can be challenging if you do not understand how the system handles the posting process for various types of transaction origins. Understanding how the modules in Dynamics GP are integrated and the posting options available will save users a lot of time and frustration if they encounter a posting interruption or need to make a correction. The Posting Setup window (Tools > Setup > Posting > Posting) is usually not accessible to the average user in GP due to security restrictions imposed by SOX compliance and general best practices for security implementation. However, it is important for users to have some knowledge of the posting options and how they affect your posting processes in the various modules. We’ve included some suggestions below for Best Practices for Posting Setups in four parts:

• Part 1 Dynamics GP – Understanding Module Integration and Transaction Origins
• Part 2 – Dynamics GP – Posting Options from Sub Ledger to General Ledger
• Part 3 –Dynamics GP – Using Batch Control Totals and Approvals
• Part 4 – Dynamics GP – Options for Printing Posting Reports.

Part 1 Dynamics GP – Understanding Module Integration and Transaction Origins

Series: The core Microsoft Dynamics GP product is divided into six main series some of which include more than one module. The breakdown is as follows:

It makes sense to tie together modules such as Payables and Purchase Order Processing in the same series due to a variety of interdependencies between tables and transaction processing. Below is a simple graphic of the core modules and how they integrate with one another and tie to the General Ledger. The arrows indicate how the information flows from one module to another.

Origin: The list includes all the types of transactions that are processed within each module that ultimately affect the posting process. For example, in the Purchasing Series, the Origin of Computer Checks represents the processing of a computer generated check batch through Select Checks, Edit Checks, Print Checks, and Post Checks.

You will also see these Origins in various Batch Entry windows such as in the figure below. It helps to familiarize yourself with the terminology used for the origins of the transactions you process.

Part 2 – Dynamics GP – Posting Options from Sub Ledger to General Ledger

Post To and Post Through General Ledger:

The Post To/Post Through options determine if transactions of the Origin type selected will Post To AND/OR Through the General Ledger. There are three options as follows:

1. Post to General Ledger – When only this option is marked, transactions that originate in the subsidiary for the origin type selected in the drop down will post to the subsidiary, and a second batch will be created in the General Ledger under Financial Batches. The batch will have a prefix that corresponds to the module and transaction origin as assigned by the audit trail codes that are setup as defaults in your system. For example, a computer check batch that posts to the subsidiary and then “Posts To” the General Ledger will have a batch prefix of PMCHK which stands for Payables Management Checks. The batch ID in Financial Batches will correspond to the audit trail code that is assigned to the Posting Journal that prints in the subsidiary ledger. In this case, the batch can be reviewed and edited if necessary prior to posting.Note: We do not recommend that you make any changes to a Financial batch without taking into consideration any corrections needed in the subsidiary as well.
2. Post to General Ledger and Post Through General Ledger Files – When BOTH options are marked, transactions that originate in the subsidiary for the origin type selected in the drop down will automatically be posted directly through the General Ledger at the same time the posting is completed in the subsidiary. This method is recommended and preferred by most clients for the easiest and most efficient posting that updates the General Ledger in real time.
3. Post to General Ledger and Post Through General Ledger Files – When BOTH options are UN-marked, transactions that originate in the subsidiary for the origin type selected in the drop down will only be posted to the subsidiary and will not have any effect on the general ledger.Note: Unmarking both of these checkboxes should be used with extreme caution as it could result in data inconsistencies between your subsidiary and General Ledger. This option is used mainly for entering beginning balances for Payables and Receivables that you only wish to post to the subsidiary and NOT to update the general ledger or in cases where you may have damaged data and you need to make a correction in the subsidiary that you do not wish to update the General Ledger.

Create a Journal Entry Per:

Transaction – If this option is selected, for every transaction created in the subsidiary for this type of transaction, there will be a separate journal entry created in the General Ledger. Basically, this option allows you to capture all the detail for transactions in the subsidiary and transfer it to the General Ledger. Please note this method is the preferred option and considered to be the best practice.

Batch– If this option is selected, a separate journal entry will be created for each batch posted in the subsidiary for this transaction type. For example, a batch of 10 Payables invoices all containing a credit to the AP control account will post to that account in the general ledger as one summary entry for the total amount of the batch. Similarly, the system will summarize any like accounts on the debit side with the PURCH type for each invoice and post the totals to the General Ledger. This option allows for quicker posting.

Note: If you select to Create a Journal Entry Per Batch, the Use Account Settings option also becomes available. If you select to Use Account Settings, the system will post either in detail or summary depending on the specifications assigned to the account in the Account Maintenance window. This option results in a slower rate of posting time. You would typically use this option for journals where you want to see a breakdown by account for expenses but a summary for the offset account. You’d set up each expense account to be posted in detail and your payables account to be posted in summary.

Allow Transaction Posting: Select this option to allow you to post this transaction type without having to create a batch in the subsidiary ledger. This option allows you to enter transactions and post them individually directly from the transaction entry window. You can post as many entries you like in the Transaction Entry window by clicking on the Post button. Any posting journals you have selected to print for the transaction type will print when you exit the window.

Note: If you select the option to Allow Transaction Posting, it will override the option to Post To and/or Post Through General Ledger. Transaction level posting updates the subsidiary and then creates a batch in the General Ledger waiting to be posted. This option can be confusing for users who are expecting to be able to Post individual transactions in the subsidiary that will automatically update the General Ledger. Keep in mind when balancing your subsidiary reports to the General Ledger detail that any transactions posted individually will need to be manually posted in the General Ledger even if you have selected to Post Through General Ledger.

Include Multicurrency Info: If you’re using Multicurrency Management, any Posting journals printed as part of the posting process will include multicurrency information. However, keep in mind that even if this option is marked, any REPRINTED posting journals will not include multicurrency information.

Posting Date From: If you use batch processing in GP, you can choose to use the posting date from the date of the batch or the date of the transaction. The figure below illustrates the difference. If you select by Batch, the Posting Date field in the Batch Entry window will default to the system date and will be available for edit.

This option will use the date that is entered on the batch header to determine what period/date the transactions will post to the General Ledger.

If you select by Transaction, the Posting Date field will be grayed out in the Batch Entry window:

When posting by the date of the Transaction, the system will use the date entered on the date field that is associated with the document such as:

You can select to override the posting date for an individual transaction by clicking on the expansion button next to the transaction date field as in the figure below:

Note: The option you select for your posting date is very important and will determine the period in which the items appear in the General Ledger. If you need to change this option, it is recommended that you do so only if there are no UNPOSTED batches for the transaction origin in question. You should either post the batch and then make the change to your posting setups, OR delete the batch, make the change to the posting setups, and then re-enter the batch.

If Existing Batch: Append or Create New. This option is relevant if you’re Posting To general ledger only AND if using Transaction Level Posting. The logic is that if there is an “Existing Batch” for this origin type in the unposted Financial Batches, do you want each subsequent posting in the subledger to Append to the Existing Batch OR Create a New batch? If you select “Append”, the system will add each subsequent posting in the subsidiary to one batch in the general ledger with a Batch ID that corresponds to the Source Doc code for the transaction origin. For example, if you chose to append batches for the Payables Trx Entry origin, the batch ID would be PMTRX.

If you choose to Create New, then each time you post at the batch level or the transaction level in the subsidiary module, it creates a new batch in the general ledger that includes both the prefix of the transaction plus a number such as PMTRX00000007 – see below for examples.

We strongly recommend to select the “Create New” option. This options allows for a much easier method of auditing and tracing transactions back to their subsidiary origin since the prefix and number assigned to the general ledger batch will correspond to the Audit Trail Code assigned to the Posting Journal in the module of origin.

Part 3 –Dynamics GP – Using Batch Control Totals and Approvals

Verify Number of Transactions and Verify Batch Amounts: These options are best suited for companies processing a large volume of transactions and that require more complex segregation of duties and/or checks and balances.

The Verify Number of Transactions and Batch Amounts requires the user to fill in Control Totals in the Batch Entry window for that specific transaction origin before the batch can be posted. The Transactions field is the actual number or count of transactions in the batch. The batch total is the absolute value of the transactions in the batch including any credit amounts. The Actual total fields will populate as you begin entering transactions in the batch. The actual transaction amount entered in the batch must match the control total before you can post the batch.

The Require Batch Approval option allows you to setup a restriction to require a higher level of approval prior to posting the batch. If you mark this selection, it will prompt you to set up a password. It will not allow you to save this option without entering a password in the Posting Setup window. When the batch is ready to be posted, it must be reviewed by a user with the appropriate authority, preferably not the same user who entered the transactions. The approver will mark the checkbox in the Batch Entry window and enter the password. The system will not allow you to post the batch until you have marked the Approve checkbox and entered a password. Once this is complete, the system will populate the USERID field with the user who approved the batch.

Part 4 – Dynamics GP – Options for Printing Posting Reports.

The last element to consider when selecting your Posting Options is the Posting Journals/Reports you wish to print when a batch in the specified origin is posted. Each Series and Origin contains at least one or more types of posting journals that are available for printing once the posting process has completed. Depending on the organization’s preferences, you may decide to print one or all of the reports or maybe none at all.

The checkbox to the far left of the scrolling window under Reports entitled Print allows you to turn printing on and off entirely for the report. The checkboxes in the middle of the scrolling window under the Send To: heading, indicate the following:

• Ask each time prior to printing the report for a destination. This selection allows you to specify an option at the time of posting/printing to print to the Screen, the printer, or a file.
• Send report directly to the Screen.
• Send report directly to the default printer designated on your computer’s Printer Setup Preferences.
• Send report directly to a File and then select the file type from the drop down box. The options are text file, tab delimited, comma delimited, html, or adobe pdf.

Select the option to Append or Replace the file. Then click on the yellow folder on the Path line and browse out to select a path for the file.

Click OK to save your changes and exit the window. OR click on Save to remain in the Posting Setup window and make a selection for another Series and Origin.

We recommend that you start off printing all the reports to either printer or screen until you are comfortable with the information and how it is presented. Once you have become more familiar with the reporting, you can be more selective with the reports you print for each series and transaction origin.

If you have more questions about module integration in Dynamics GP, RSM offers access to Certified Microsoft Professionals, help desk and phone support, knowledge and experience with third party products and dedicated account management.  Please contact our professionals for more information at erp@rsmus.com or by phone at 855.437.7202.

By: Nancy Hogan – Pennsylvania Microsoft Dynamics GP partner

Nancy Hogan