Planning: Microsoft Dynamics GP System


Microsoft Dynamics GP 2010 Implementation

Microsoft Dynamics GP 2010 Implementation

A step-by-step guide to implementing Microsoft Dynamics GP 2010

  • Master how to implement Microsoft Dynamics GP 2010 with real world examples and guidance from a Microsoft Dynamics GP MVP
  • Understand how to install Microsoft Dynamics GP 2010 and related applications, following detailed, step-by-step instructions
  • Learn how to set-up the core Microsoft Dynamics GP modules effectively
  • Discover the additional tools available from Microsoft for Dynamics GP


        Read more about this book      

(For more resources on Microsoft Dyanamics, see here.)

Companies in Dynamics GP

A critical decision that is very difficult to change after implementation is whether or not to have multiple companies in Dynamics GP. Sometimes there is no question, as there is only one company or there are clearly separate entities. However, often there are multiple legal entities, branches, or subsidiaries that may require separate accounting records and procedures, but also share customers or inventory items.

There is no limit on the number of companies you can setup in Dynamics GP. Each company created becomes a separate SQL Server database and behaves autonomously, save for a few shared characteristics global to the entire Dynamics GP installation, such as system users, currency setup, and exchange rate tables.

There are situations when separate companies are clearly recommended in Dynamics GP:

  • If accounting records must be kept in different functional currencies to conform to local requirements
  • When using Dynamics GP Payroll and there are different Federal ID Numbers
  • If there are entities that have different fiscal periods
  • Some types of businesses require separate accounting books to be kept to comply with various federal and state regulations

If the requirement is simply to keep separate General Ledger accounts for each separate entity, this is fairly easy to accomplish within one Dynamics GP company. In some situations, there is no right or wrong answer as to whether to have one or multiple companies, the following sections will discuss the benefits of the two approaches in more detail.

Benefits of having one company in Dynamics GP

The benefits of having one company in Dynamics GP are as follows:

  • Initial company setup is faster: Even if there are different General Ledger accounts for multiple entities within one company, there are significant time savings in only having one Dynamics GP company to set up.
  • Ongoing maintenance and support are simpler: Multiple companies add ongoing incremental time, and thus cost, to maintenance and support. Even though many maintenance tasks can be automated, monitoring and support is simpler for a single company database. Any changes, service packs, or additional products installed may need to be performed separately for each company. Upgrades will typically take less time for one large company database than multiple smaller ones.
  • Less storage space is needed: Having multiple databases in SQL Server increases the storage space needed because each separate database will have some duplicated overhead. Also keep in mind that each additional company will require added capacity for backups. This benefit may not be so important anymore, with storage being much more affordable than it has been in the past, but it is still something to consider.
  • Yearly processing is faster: Yearly closing for various modules only has to be done once if there is one Dynamics GP company. Other yearly company-specific tasks, such as creating new fiscal years and yearly budgets, will take less time with one company.
  • Reporting is simpler: Typically creating reports for one company takes significantly less time. There are no built-in multiple-company reports in Dynamics GP.
  • Ability to share vendors, customers, and inventory items: Dynamics GP does offer an Intercompany module, but it is fairly limited. For example, there is no way in Dynamics GP to sell an inventory item from one company to a customer in another company. (There are third-party add-on products that can help with this.)
  • Imports and integrations with other systems may be simpler: Typically, imports and integrations with other systems are more straightforward to set up and maintain with only one Dynamics GP company.
  • Availability of additional products or modules is not limited: There may be some modules or products that will not support multiple Dynamics GP companies easily. Having one company will obviate any concerns about this.

Benefits of having multiple companies in Dynamics GP

The following is a list of the benefits of multiple companies in Dynamics GP:

  • Very clear delineation between companies: All the records for each entity are clearly separated. Having multiple companies makes it more difficult to enter something in the wrong company.
  • Ability to separate vendors, customers, and inventory items: This is the flip side to not being able to share vendors, customers, and inventory items and may be a benefit rather than a hindrance, depending on your requirements. For example, if your customers consider your divisions or subsidiaries to be separate companies, they would expect to receive separate statements from each company and pay each separately. Having all the transactions in one Dynamics GP company could make it very difficult to accomplish that separation without a lot of customization.
  • Security: Additional security options are a direct result of the ability to separate vendors, customers, and inventory items. Consider a situation where you acquire a subsidiary and do not want all of your newly acquired employees to see any of the General Ledger details, customer information, or inventory details from your main company. With only one Dynamics GP company, it is impossible to achieve this without significant customizations, but a separate Dynamics GP company automatically accomplishes this.
  • Ability to perform yearly closing at different times: This could be a benefit if the accounting and yearly closing procedures vary for the different entities.
  • Different setup options possible for each company: An example of this may be different receivables aging buckets needed or aging performed a different way for different lines of business. The only way to accomplish this within one Dynamics GP company is with custom reports, however, separate companies make this a non-issue.

Whether to set up one or multiple companies is a topic that should be carefully considered when planning your Dynamics GP implementation. If you are not sure of the proper approach for your specific situation, carefully go through your business requirements, as well as legal and other governmental regulations, and speak to your Dynamics GP resource in detail to help determine the best course of action.

Once the decision is made, you will need to have a company name and a database name for each company you are planning to set up:

  • Company name: Maximum of 65 characters. This is what users will see when they log into Dynamics GP and are presented with a list of companies. It will also be what is defaulted at the top of most reports to identify the company, and what shows on every window when using Dynamics GP. Even though 65 characters are possible, it is recommended to keep this shorter, as only 35 characters will typically fit on the login screen. If you are planning to create multiple Dynamics GP companies, make the names different enough so that there is no confusion for users. (Example: Not Just Widgets, Incorporated)
  • Database name: Maximum of five characters. This will be the SQL Server database name. It should be alphanumeric and cannot start with a number or have special characters. While most end users may never see the database name, more technical users and system administrators may use it quite often, and it may be seen on reports and used for some setup steps. (Example: NJW)

Integration with other systems

Are there existing systems in place that your Dynamics GP system will need to integrate with? A good example of this in many companies is a sophisticated web application already in place for customer orders and billing. Other examples may be systems for employee time tracking, fixed assets, or shipping software.

Excel spreadsheets, no matter how complex, are not usually considered existing systems. Existing systems are most likely to be other database applications or separately purchased software packages to accomplish specific tasks.

If there are existing systems in place, part of the implementation planning will be to decide whether to keep these systems and integrate them with Dynamics GP, or replace the functionality with Dynamics GP. Other approaches may be hybrids of these: keep some existing systems but replace others, or keep existing systems for now and replace their functionality with Dynamics GP in a more phased approach, one at a time, after the implementation.

To help decide on the best approach, ask the following questions, keeping in mind that the goal, whenever possible, should be a single data entry point:

  • How well does the existing system fulfill the current requirements? If the system is not meeting today's business needs, because it was created ten years ago and met the requirements then but they have changed significantly, then it is a good candidate for replacement. However, if the existing system is accomplishing what is needed, even if a few small tweaks are needed, it may be best to keep it.
  • How easy would it be to integrate the current system with Dynamics GP? There are a few parts to this question:
    • Would it be fairly straightforward to import data from the current system into Dynamics GP? Or would considerable work be needed?
    • Does the data flow need to go one way only (from the existing system to Dynamics GP), or does it need to be bidirectional? If bidirectional, what is the process of importing data into the existing system?
    • How timely does the integration have to be? Should new data be imported into or out of Dynamics GP monthly, weekly, daily, or real-time?

    If the data import is fairly straightforward and one of the existing Dynamics GP import tools can be used, that would make a decision to keep an existing system in place more viable. If creating the integration would require considerable work and real-time integration is needed, it may be a good candidate for replacement, especially if the existing system is not meeting all the current requirements.

  • What would be the cost of replacing the functionality with Dynamics GP? While the existing system may be sufficient, it may also be fairly easy to duplicate its functionality with Dynamics GP. If that is the case, the decision should be based on the comparison of the cost of duplicating the functionality in Dynamics GP (which may involve an additional module purchase or customization), and creating and maintaining the integration. In this situation, even if the cost of moving the functionality to Dynamics GP is slightly higher upfront, it is better to not keep the existing system, as having only one system to maintain will pay for itself in the long run and will also result in increased end user satisfaction.
  • Will keeping the existing system prevent any planned upgrades? The current system may be performing perfectly and meeting all the business needs. However, it may be a custom application that is no longer supported or one that has a very costly upgrade path to move to new operating systems, versions of SQL Server, or some other planned technology upgrade. This may make it a good candidate for replacement with a phased approach, after the Dynamics GP implementation.

Once these questions are answered, compare the cost and time of keeping the current systems, and creating integrations, with the cost and time of replacing them. Keep in mind that there are many third-party (also called Independent Software Vendor or ISV) add-ons available for Dynamics GP, even if the functionality needed is not available in Dynamics GP out-of-the-box.

        Read more about this book      

(For more resources on Microsoft Dyanamics, see here.)

General Ledger Chart of Accounts

The key building block of the Dynamics GP system is the General Ledger account. Prior to installing Dynamics GP, you will need to determine your Account Framework and Account Format.

Account framework

The account framework sets the maximums and sorting options that will be available for all your Dynamics GP companies.

Dynamics GP allows the following maximums for the account framework:

  • Up to 10 account segments.
  • Up to 66 characters, not including separators between segments.
  • Maximum of 82 bytes. Bytes are calculated as the length of each segment plus 1 for each segment with an odd number of characters, or plus 2 for each segment with an even number of characters. For example, an account framework with 7 segments of 6 characters and 3 segments of 8 characters will have 86 bytes: ((6+2) * 7) + ((8+2) * 3) and thus will not be allowed.

In the past, there may have been space considerations that would justify limiting the account framework chosen when installing Dynamics GP. This is usually not the case anymore and even if a 10 segment General Ledger account will never be needed, a typical account framework is the following: maximum of 66 characters and 10 segments of six characters each.

Even though this only adds up to 60 characters, this is fine, 66 is simply the maximum. Having a standard account framework simplifies setting up development environments and moving installations in the future.

The main reason to think about the account framework at this stage is if you foresee needing account segments longer than six characters. You will need to make sure that the account framework selected when you install Dynamics GP encompasses the maximum GL account length you will need. Changing the account framework after the Dynamics GP installation is possible, but not trivial and would require an additional tool or service to be purchased.

Account format

The General Ledger account format can be different for each Dynamics GP company, as long as it is within the account framework defined during the Dynamics GP installation.

General Ledger accounts can be alphanumeric and Dynamics GP will add a separator character of your choosing in-between the segments. While the separator can be different for each company, the most commonly used separator is a dash ( — ).

Even though Dynamics GP will allow for a very long GL account number and it may be tempting to track many details in the General Ledger, this is not recommended. Most Dynamics GP windows will only display approximately 25 characters without having to scroll to see the entire account. Best practice is to keep the account number to three or four segments and a total of no more than 15 or 20 characters, including the separators.

Here are examples of some common account formats:

Account Segment details
4000-100-10 Natural Account-Division (or Cost Center)-Location
01-5050-250-00 Company (Entity)-Natural Account-Subaccount-Department
03-62100-000 Location-Natural Account-Subaccount
5100-60-05-10110 Natural Account-Department-Region-Cost Center

At this stage of your implementation planning, you should decide on the account format for each Dynamics GP company planned and start putting together your General Ledger Chart of Accounts. If you are planning on multiple Dynamics GP companies and will need consolidated financial reports or other multi company reports based on GL account numbers, it is highly recommended that all the companies have the same account format and that the Chart of Accounts be as similar as possible.

Additional notes for the General Ledger Chart of Accounts in Dynamics GP:

  • You do not need to create roll-up accounts in Dynamics GP. Any roll-ups needed for financial statements can be accomplished when setting up the financial statements. Roll-ups ups for inquiries can be created in Dynamics GP without having to explicitly define accounts for them. For example, if there are four individual accounts for travel expenses (Airline, Lodging, Car, and Other Travel), there is no need to create a fifth account called Travel.
  • All General Ledger accounts should be predefined ahead of time. It is not enough to create a list of all natural accounts and a list of all possible values for each of your other segments. While Dynamics GP can create accounts on the fly, this is not recommended. Most users are typically not given the security to create GL accounts and there is a high potential for errors and inconsistencies when this is done.
  • It is not recommended to have spaces in your GL account numbers. Spaces will make using the account numbers difficult for users and may also cause reporting issues, as reporting tools may interpret spaces differently. Instead of spaces use zeros.
  • The General Ledger account name can have a maximum length of up to 50 characters and can be changed at any time.

When deciding on the Chart of Accounts, keep in mind the reporting requirements you have identified during your business requirements planning. Try to keep accounts that will be in the same groupings on the Balance Sheet and Profit & Loss Statements together, leaving enough room for inserting accounts in the future.

The following table is a list of the minimum data required for General Ledger account setup:

Data Details Example
Account Number This should be the entire account number, including separators. 4000-100-10
Account Name String with a maximum of 50 characters. It is recommended to make the account name (also referred to as Account Description) as complete as possible to help users find the appropriate account easily during transaction entry. Sales-Hardware-US
Category Dynamics GP has a preset list of categories available-these can also be modified or added to if needed. In most cases, categories do not add much to functionality, but they may be helpful when looking at a Chart of Accounts or creating financial statements and are required for all General Ledger accounts. Sales
Posting Type Balance Sheet or Profit and Loss-this option is important for Dynamics GP, as it determines whether the account balance needs to be brought forward to the next year during the year-end close process or closed into Retained Earnings. Profit and Loss
Typical Balance Debit or Credit-this is not too critical, however it is a required field when setting up a new GL account. This setting sometimes helps to default data during General Ledger transaction entry. Credit

Master record IDs and names

Dynamics GP has an ID and a name for each master record. Both are strings and all IDs within the same type of record must be unique, while names can be duplicated. IDs in Dynamics GP will always be in capitals. Special characters (anything other than letters or numbers) are allowed in IDs and while spaces or dashes are fine to use, other special characters should be discouraged. There is a much higher potential for application errors if special characters have not been properly excluded or coded around. It is also sometimes difficult to differentiate between some special characters when looking at an ID on the screen.

Some companies prefer to have IDs that are numeric only and use the next number available for any new record. Others decide to use IDs that are more descriptive and use mostly alpha characters. Both of these approaches are fine, however it is recommended that the numbering scheme for each type of record is consistent for all records created. The following are two important points to keep in mind when deciding on numbering schemes:

  • Dynamics GP does not have the functionality to automatically suggest the next number available when only using numeric IDs. The user creating the new record will have to determine what the next ID number should be. (There is a third-party add-on that offers this functionality for the core Dynamics GP modules.)
  • Just about every transaction entered and lookup used in Dynamics GP will require one or more ID to be entered by the user. While auto-complete and lookups help with this, it is typically more user friendly to use IDs that will be easily recognizable by the users.

There are many possible numbering schemes, consider some typical examples for a vendor called American Express:

Vendor ID Explanation and notes
AMEX What the vendor is typically called, this is easy to use and remember, however not all vendors will lend themselves easily to this type of ID.
10001 A numerical ID, regardless of the vendor's name. This method ensures that all the IDs are the same length, which is better for reports, however it is typically more difficult for users, because it can add an extra step to the process of entering an ID for every transaction or lookup window. One advantage this numbering scheme provides is that if the vendor changes their name, the ID is independent of the name.
AMERICANEXPRESS This ID may make it easier for users to find the vendor, however it is a lot to type and not all vendors will easily lend themselves to this type of ID.
AMEEXP or AME001 First three letters of the first word and second word of the vendor name, or the first three letters of the first word and a sequential number. Again, this makes all the IDs the same length and it also provides a bit of structure to the numbering scheme that is straightforward for users to follow.
AMERICAN EXPRES As much as will fit of the vendor name, including spaces. This makes it easier for users to find, but may look strange for some vendors when cut off, like in this example.

We have seen all of the numbering schemes above implemented, probably the hardest for users to work with is the method of using only numbers in IDs.

To illustrate the use of these numbering schemes, the following screenshot shows an example of what users would see if they start typing AM in the Vendor ID field on a payables transaction when using the auto-complete feature:

All the IDs suggested previously will show in the auto-complete choices, except the numeric one. In addition, using a numbering scheme like AME001 may result in many others, such as AME002, AME003, and so on, for company names starting with American. On a list such as this, it would be impossible to tell what those IDs represented without memorizing them. So, the user would have to either click the <<More...>> option or the Lookup button to open the Vendors lookup window and see additional choices:

As you can see in the preceding screenshot taken from the Dynamics GP sample company (Fabrikam), many of the Vendor IDs are the first eight letters of the name and a four digit number. In most companies the likelihood of having ten thousand vendors having the same first eight letters is remote, so this is not a commonly seen numbering scheme for implementations we have worked with.

Whether you have decided to renumber and rename your vendors, customers, inventory items, or fixed assets, or just clean up the existing data, make sure that what you are planning will work with Dynamics GP. The following are field lengths for the most common Dynamics GP master record IDs and names:

Master record ID length Name length Notes
Vendor 15 65 Some built-in reports or windows may not show all 65 characters of the vendor name. On the Vendors lookup window (shown on the previous page) only the first 35 to 40 characters will show.
Customer 15 65 Some built-in reports and windows may not show all 65 characters of the name. On the Customers lookup window only the first 35 to 40 characters will show.
Inventory Item 30 100 Many built-in reports may only show 50 characters of the item name, as this was the original length of this field before it was increased a few versions ago.
Inventory Site 10 30 Typically all 30 characters of the name will show on lookups.
Fixed Asset 15 40 Additional description fields are also available for assets.
Checkbook 15 30 Typically all 30 characters of the name will show on lookups.
Salesperson 15 15 +15 +20 First Name (15 characters), Middle Name (15 characters), and Last Name (20 characters) are available for salespeople.
Sales Territory 15 30 Typically all 30 characters of the name will show on lookups.

Once created, master record IDs are not editable in the out-of-the-box Dynamics GP. The Professional Services Tools Library (PSTL), available as a separate purchase from Microsoft, contains many useful tools, including ones allowing modification of all the master record IDs listed previously as well as General Ledger accounts. There are also tools available in the PSTL to combine the following: Vendor IDs, Customer IDs, General Ledger accounts, Inventory Item IDs, and Inventory Site IDs.

Knowing tools are available to make changes in the future may take some of the pressure off the numbering scheme decisions upfront. However, they are still important decisions that should be well thought out, as making changes after the implementation can be costly and time consuming. Typically we do not see companies having the need to modify master records for the first year or two after the initial Dynamics GP implementation, unless there is a significant change in the business.

Fiscal periods and years

Dynamics GP allows an unlimited number of historical and open fiscal years.

Dynamics GP manuals and online help state that you can only post transactions to two open years. This is not the case—you can post transactions to any and all open years you have in Dynamics GP.

The following are guidelines for fiscal years and periods in Dynamics GP:

  • Each fiscal year can have up to 367 fiscal periods.
  • Fiscal years cannot overlap.
  • Each fiscal period within a fiscal year can have a different length.
  • Fiscal year names can only be a four digit year number.
  • Up to three periods can have the same starting date. This is sometimes, although rarely, used for adjustment periods and is typically not recommended. Best practice is to not have overlapping fiscal periods.
  • You can make changes to fiscal periods after they have been set up.
  • You can only post transactions to the last historical (closed) fiscal year. For example, if 2007 and 2008 are closed you can still post to 2008, but you cannot post to 2007 anymore.

Most companies have fiscal years that are calendar years and choose to have 12 periods (one for each month), so the fiscal period setup would look like the following example:

If your company fiscal year is not the calendar year, most likely the year is referred to by the date it ends. For example, if the fiscal year is from July 1, 2009 to June 30, 2010, it will typically be referred to as Fiscal Year 2010. This is more of an accepted convention and Dynamics GP will not enforce the naming of your years. If you think that there is a possibility you will want to change to a calendar year fiscal year sometime in the near future, consider renaming your years during your Dynamics GP implementation to use the number of the beginning year, for example:

Fiscal Year Start Date End Date
2008 July 1, 2008 June 30, 2009
2009 July 1, 2009 June 30, 2010
2010 July 1, 2010 June 30, 2011

This approach will allow you to seamlessly add a short year whenever you are ready to switch to a calendar year:

Fiscal Year Start Date End Date
2011 July 1, 2011 December 31, 2011
2012 January 1, 2012 December 31, 2012

An alternative to this is to keep the fiscal year naming you currently have and if the change to a calendar year is made, purchase a tool from Microsoft called Fiscal Period Modifier (part of the PSTL), which will allow you to rename your existing years.


In this article, we have focused on planning for the Dynamics GP system setup. We went over the important factors in choosing how many companies to have in Dynamics GP and what to consider when deciding whether to integrate with existing systems or replace them. General Ledger account frameworks and account formats were examined and master record numbering schemes were discussed. We discussed fiscal periods, fiscal years and recommendations for non-calendar fiscal years.

Further resources on this subject:

You've been reading an excerpt of:

Microsoft Dynamics GP 2010 Implementation

Explore Title