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:
