IT tutorials
 
Applications Server
 

Microsoft Dynamic GP 2010 : Dynamics GP System - Additional setup considerations

1/25/2013 11:23:23 AM
- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

In addition to the setup categories we have discussed so far, there are a few more topics that are sometimes not looked at until after installation but that you may want to consider prior to setup.

Shipping Methods

Shipping Methods are company specific and are used to define all the possible shipping options a company uses to deliver goods to customers or receive goods from vendors. During the Dynamics GP installation a default list of shipping methods can be installed.

The two major functions of shipping methods are to communicate the shipping information to employees, customers, and vendors on transactions and documents, and to determine what taxes are calculated automatically by Dynamics GP. For example, if the shipping method on a customer invoice has a type of Delivery, then the customer's shipping address will determine the tax. If the shipping method has a type of Pickup, then your company's warehouse location will determine the tax.

Payment Terms

Payment Terms are company specific and define the terms offered to customers and available from vendors for payment of invoices. Default payment terms can be loaded during the Dynamics GP installation and can be changed or added to as needed.

If your company has a large list of available payment terms, you may want to identify them ahead of time so that they can be created during the implementation. Payment terms, when set up for customers and vendors, will default on all transactions and automatically calculate due dates, making transaction entry faster and more accurate.

Credit Cards

Credit Cards can be set up in Dynamics GP to be used for payment to vendors and to be accepted as payment from customers.

Credit cards accepted from customers

There are two options for credit cards accepted from customers:

  • Bank Card / Checkbook ID: This will associate a credit card with a bank account (also called Checkbook) in Dynamics GP. When a customer payment is entered using this type of credit card, the payment amount will automatically go to the bank account specified. This setup option is typically used when the full amount of the credit card charge is deposited into the company's bank account by the credit card processor, and the credit card processing fees are taken out separately on a monthly basis.

  • Charge Card / Account Number: This will link the credit card to a General Ledger account. When a customer payment is entered using this type of credit card, the payment amount will be posted as a debit to the GL account specified, and will require a separate entry to move the payment out of this GL account into the cash account. This type of credit card setup is useful when the credit card processor takes their discount or fees out of every transaction. For example, a customer pays $500 with a credit card, but only $487.50 is deposited into the bank account with a $12.50 fee deducted right away.

Credit cards used to pay vendors

There are also two options for setting up credit cards used to pay vendors:

  • Credit Card / Vendor ID: This will associate a credit card with a vendor in Dynamics GP. When a vendor payment is entered using this type of credit card, the payment amount will automatically create an invoice payable to the credit card Vendor ID specified. This setup option should be used for traditional credit card accounts that send a monthly statement to be paid separately. 

  • Check Card / Checkbook ID: This option will link the credit card to a bank account (Checkbook) in Dynamics GP. When a vendor payment is entered using this type of credit card, the amount will be posted as a cash withdrawal from the Checkbook specified. This credit card setup is used for what is commonly called Debit Cards, where each purchase is deducted from the bank account right away.

Credit card setup is company specific in Dynamics GP. Multiple companies cannot share credit cards.

Posting setup

Each type of transaction posted in Dynamics GP can be set up to behave differently. Posting settings are company specific, so the same type of transaction can have different settings in each Dynamics GP company. All of the posting settings can be changed at any time, but there are a few important settings that may require additional discussion or planning ahead of time: Post Through General Ledger Files, Create a Journal Entry Per, Posting Date From, and Require Batch Approval.

The following is an example of what the posting settings may look like for transactions originating on the Payables Transaction Entry window in Dynamics GP:

Post Through General Ledger Files

With very few exceptions, all transactions in every subledger will be set to Post to General Ledger. This will create GL entries after the subledger posting is completed. Choosing the Post Through General Ledger Files setting will automatically post the resulting GL entries at the time of the subledger posting. If this setting is not chosen, a user will need to post the GL entries that have been created from subledger postings as a separate step.

Many companies, when first starting to use Dynamics GP, decide not to have transactions automatically posted through to the GL. This gives them the chance to examine the General Ledger entries created and make sure they understand how the system is behaving with regard to dates and account numbers defaulted. However, as it takes less time and work to have transactions automatically posted through to the GL, eventually many transaction types are changed to use the Post Through General Ledger Files option.

Create a Journal Entry Per

When posting a subledger batch with multiple transactions, the Create a Journal Entry Per setting determines whether a General Ledger entry is created for each individual subledger transaction, or whether one GL entry is created summarizing the entire subledger batch.

Choosing to create one GL entry per subledger Transaction allows for greater drill-back capability. When looking at a particular General Ledger entry it is possible to drill back down to the originating transaction in the subledger. The benefit of choosing to create one GL entry per subledger Batch is that the GL does not get as cluttered up with individual transactions.

Consider a company that has 500 sales invoices a day. If each of these creates a GL entry, in a 260 workday year, that will result in 130,000 GL entries, just from the sales invoices. Many sales invoices will have numerous GL distributions, so with an average of 8 GL distributions per invoice, that will become 1,040,000 lines in the GL per year from sales invoices alone. Typically this much detail is not needed, as no one will be looking through it at this detail level. In this scenario, if those 500 invoices are split into five batches per day, then only five GL entries are created each day, resulting in 1,300 GL entries per year for sales invoices.

To determine the right approach, consider the volume expected for each type of transaction. If there is any question, the recommendation is to err on the side of having more detail and creating a GL entry per transaction. It is much easier to summarize detailed data with reports than to recreate detail not kept from summaries. This setting can always be changed in the future as transaction volume increases.

Posting Date From

Every subledger transaction in Dynamics GP will have two dates: a subledger date and a General Ledger date. The subledger date is typically the actual date on an invoice received from a vendor or sent to a customer. The General Ledger date is the date a transaction will show up on financial statements.

Dynamics GP easily allows these two dates to be different and keeps track of all the dates throughout the accounting process. Reports that are printed will usually have an option for selecting transactions using the subledger date (also referred to as Document Date) or the GL date (also referred to as the Posting Date or GL Posting Date). For example, a company may need to print two different Receivables Historical Aged Trial Balance reports: one using the subledger dates, which are actual invoice dates, to see the true aging of customer accounts, and another using the GL dates to reconcile the Receivables subledger to the General Ledger.

The two choices for the Posting Date From setting are Batch and Transaction. Choosing Batch means that all transactions entered in the same batch will be posted with the same GL date, set at the batch level. Choosing Transaction will allow each transaction within a batch to have its own GL date. If Create a Journal Entry per Batch is selected, this option will be grayed out and automatically set to Batch.

As dates are critical to keeping accounting records accurate, this setting should be considered carefully and may need to be different for different types of transactions, depending on how they are entered or imported into Dynamics GP. The more commonly seen recommendation is to set the Posting Date From option to Transaction to allow for greater control during transaction entry.

Require Batch Approval

For certain types of transactions it may be helpful to prevent users from posting their transaction batches until someone else has reviewed and approved them. In many companies this is accomplished with training and there is no need to have Dynamics GP enforce this behavior. However, if desired, the Require Batch Approval setting in Dynamics GP will ensure that a batch cannot be posted without an Approval Password.

Multicurrency

If you have decided to use the Multicurrency module, currencies and exchange rate tables should be planned out.

Currencies

Determine all the currencies that will be used and what the ID for each currency should be. Additional considerations for currencies are the symbols to use, the number of decimal places to keep, what separators to use for decimals and thousands, and what company in Dynamics GP will have access to each currency. The following is an example of a typical Currency Setup window:

Exchange Rate Tables

If using Multicurrency, decide what the source for your exchange rates will be and whether to use one or more rate type. Dynamics GP allows for SELL, BUY, and AVERAGE rates, however there is no requirement to use all of them. Many companies use only a single AVERAGE rate. Another decision is how often the exchange rate table should be updated. The following is an example of the Multicurrency Exchange Rate Table Setup and Multicurrency Exchange Rate Maintenance windows:

 
Others
 
- Microsoft Dynamic GP 2010 : Dynamics GP System - Users and security, Sales and purchase taxes
- Microsoft Dynamic GP 2010 : Dynamics GP System - Fiscal periods and years
- Microsoft Dynamic CRM 2011 : Categorizing a Report
- Microsoft Dynamic CRM 2011 : Sharing a Report, Scheduling a Report
- Microsoft Lync Server 2010 : Using Operating System Firewalls with Lync Server
- Microsoft Lync Server 2010 : Using Network Layer Firewalls with Lync Server
- InfoPath with SharePoint 2010 : Central Administration - Manage Form Templates
- InfoPath with SharePoint 2010 : Central Administration - Upload a Form Template
- Microsoft Dynamic AX 2009 : Developing Web User Interface Components (part 5) - BoundField Controls, Web Parts
- Microsoft Dynamic AX 2009 : Developing Web User Interface Components (part 4) - AxToolbar, AxPopup
 
25 Inspiring Game of Thrones Quotes
 
Top 10
 
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
programming4us programming4us
 
Popular tags
 
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS