Planning: Microsoft Dynamics GP System

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.