As a start to your Microsoft Dynamics GP implementation, we will go over some key concepts to help you plan and carry out the best implementation possible. Some of the terminology within Dynamics GP may be new to you, so we will start with some key definitions in this chapter. We will also go over the Dynamics GP licensing and application structure, so that you can make sure you have all the components you need as you start your implementation.
In this chapter you will learn about the following:
The structure of Dynamics GP: What modules and series are, and how they all work together
Dynamics GP licensing
How Microsoft SQL Server and Dynamics GP work together
The definitions of Dexterity and product dictionaries
Financial reporting choices: Management Reporter, AFA, and FRx
Microsoft Dynamics GP is a modular application. In this case, a module refers to a set of related functionality within the application. A module can be as robust as Payables Management (typically referred to as Accounts Payable), which contains all the details about your vendor transactions, has over fifty windows and tables, and hundreds of stored procedures. A module can also be as narrow in scope as Customer/Vendor Consolidations, which allows you to define relationships between vendors and customers and only has a few windows, tables, and stored procedures.
When implemented together, the Dynamics GP modules integrate to provide a fully functional ERP (Enterprise Resource Planning) application. There are over one hundred modules available for Dynamics GP and it is sometimes tempting to simply install them all, or install every module included in your licensing. Don't do this! Installing modules that you do not need may result in adverse behavior in other modules, and may make administration of Dynamics GP more cumbersome than it needs to be. Best practice is to keep it as simple as possible, plan for and implement only the modules you need.
In Dynamics GP, modules are grouped into series by related functionality. For example: Payables Management, Purchase Order Processing, Purchase Order Enhancements, and Scheduled Payments modules all deal with vendor transactions and are grouped into the Purchasing series. Navigation in Dynamics GP is performed by series, as are many setup and maintenance tasks.
Before you start your Microsoft Dynamics GP implementation, it is important to understand what modules you own and how the licensing structure works. This may change some of your plans for Dynamics GP or help you determine additional purchases needed prior to implementation.
The licensing structure has been drastically changed starting with Dynamics GP 2013, so even if you were familiar with Dynamics GP in the past, you may need to take some time to familiarize yourself with the new options. If you are upgrading to Dynamics GP 2013 from a previous version, you will need to upgrade your license with Microsoft.
The new licensing model for Microsoft Dynamics GP 2013 is called Perpetual Licensing and is intended to greatly simplify purchasing Dynamics GP. The core components of the new licensing are the Starter Pack, the Extended Pack, the Full User, and the Limited User. Additional modules and options are available for purchase separately. Description of the Perpetual Licensing components are in the following table:
Full Users and Limited Users are sold on a concurrent user basis—you can have an unlimited number of users set up in the system, as long as the number of users logged in at any one time does not exceed the number of licenses you own.
Module Based Licensing is no longer sold to new customers. Business Ready Licensing will be sold to new customers until June 2014 if they are purchasing Microsoft Dynamics GP 2010.
There is a set of core modules that will be found in almost every installation of Dynamics GP. These are key modules that perform basic accounting functions and are the modules we will focus on in our implementation planning and examples throughout this book. The following are descriptions of the core modules that will be found in most Dynamics GP implementations. All of these modules are included in the Starter Pack under Perpetual Licensing:
Dynamics GP System Manager: The System Manager is the mandatory core module that controls the Dynamics GP application, users, companies, and security.
General Ledger: Everything in accounting ultimately ends up in the General Ledger (GL). This module is the final stop for all other modules and controls the chart of accounts as well as the individual General Ledger transactions and account balances. While technically possible, it would be extremely difficult to implement a functioning Dynamics GP system without the General Ledger.
Payables Management: Commonly referred to as Accounts Payable (AP), this subledger holds the details for all vendors and vendor transactions.
Receivables Management: Also called Accounts Receivable (AR), this subledger holds the details for all customers and customer transactions.
Bank Reconciliation: This module holds details for all cash transactions and bank accounts (called Checkbooks). Cash movements from other modules, such as Payables Management and Receivables Management, are posted to Bank Reconciliation.
Fixed Assets: All the capital assets of a company can be tracked in this module. Depreciation and amortization of assets is performed in Fixed Assets and sent to the General Ledger.
Inventory Control: This module holds the setup for any items sold or used by a company. This can include items stocked in inventory, services that need to appear in detail on customer invoices, or internally used items that need to have quantities tracked. Inventory Control allows for multiple warehouses or locations, serial number or lot tracking, unit of measure setup, and cycle and physical inventory counts.
Purchase Order Processing: Detailed purchase orders with line items are entered and printed in this module, which allows for a transaction flow from purchase order, to receipt of goods, to invoice. The Purchase Order Processing module helps integrate Inventory Control and Payables Management, and also works with Sales Order Processing.
Sales Order Processing: Detailed sales transactions with line items are entered in Sales Order Processing, which allows for a transaction flow from quote to order, to back order, to fulfillment order/invoice. Customer invoices and returns with line item detail are created and printed in Sales Order Processing. This module integrates Inventory Control and Receivables Management, and also works with Purchase Order Processing.
The interaction between these core modules is illustrated in this diagram:
Older versions of Dynamics GP, when it was still called Great Plains, supported installation on three different database platforms: c-tree, Pervasive PSQL (previously called Btrieve), and Microsoft SQL Server. Starting with version 8.0, Microsoft Dynamics GP is only supported on Microsoft SQL Server. With Dynamics GP 2013 the supported versions of SQL Server are 2008, 2008 R2, and 2012.
While I have not heard a single complaint about not being able to support Dynamics GP on c-tree and Btrieve anymore, there are some legitimate complaints about Dynamics GP not taking full advantage of Microsoft SQL Server. Understanding the evolution of an application helps explain the reasons for this and, with every new version, Microsoft has been enhancing Dynamics GP to make more use of SQL Server functionality. However, it is important for implementers to have an understanding of the aspects of Dynamics GP behavior that do not always take full advantage of Microsoft SQL Server.
Note
An excellent discussion on this topic can be found on the Developing for Dynamics GP blog:
Understanding how Microsoft Dynamics GP works with Microsoft SQL Server: http://bit.ly/18fvKo3
Understanding how Microsoft Dynamics GP works with Microsoft SQL Server continued: http://bit.ly/18fvTrE
One key aspect that you may find surprising if this is the first time you are working with Dynamics GP is that it only uses SQL Server authentication. User logins created in Dynamics GP are automatically created in SQL Server and the passwords are encrypted. Security for all Dynamics GP functionality is handled inside the application itself and, as the SQL Server passwords are encrypted by Dynamics GP, you are not easily able to use the same SQL Server logins for any other purpose. While good for security, this makes it more difficult when integrating other applications and is important to keep in mind when planning your infrastructure.
Some tasks within Dynamics GP must be performed while logged in as the SQL Server sa (system administrator) user. Examples of these tasks are creating new Dynamics GP users, installing and initializing additional components and third-party add-ons, and running various tools provided by Microsoft for Dynamics GP. There are workarounds available for some of these, but they do not completely take away the need for using the SQL Server sa user in Dynamics GP.
Another remnant of the older database platforms is a SQL Server and Dynamics GP user called DYNSA that gets created automatically during the Dynamics GP installation process. This user does not need to have any rights within the application, but it is critical for this user to be the database owner of all the Dynamics GP databases. Even though day-to-day operations do not typically rely on the database owner, installation of new modules, creation of new companies, and upgrades or service packs may fail if the database owner is not DYNSA.
A Dynamics GP ISV, FastPath, has a whitepaper on minimizing the use of sa in Dynamics GP which is available at http://bit.ly/15YoCLs.
When you install Dynamics GP, a global system database is created. In prior versions of Dynamics GP this database was forced to be called DYNAMICS. Starting with Dynamics GP 2013 you can change this name for new installations. The system database holds all system-wide settings such as users, companies, security, multicurrency settings, exchange rate tables, intercompany setup, and any other information that needs to be shared globally in Dynamics GP. Active processes and logins are also stored in the system database.
There is no limit on how many companies you can create in Dynamics GP. Every new company will be a new SQL Server database. The only restriction is for the SQL Server database ID to be five characters or less and to not start with a number.
A sample company is available to be installed with sample data for many of the Dynamics GP modules. The sample company is called Fabrikam and in versions prior to 2013 the database ID used to be TWO (because in older versions of Dynamics GP the sample company was called The World Online). Starting with Dynamics GP 2013 you can change this database ID to be whatever you would like within the naming restriction of five characters or less and not starting with a number.
Only two Microsoft SQL Server sort orders are supported by Dynamics GP:
The recommendation for new installations is to use the DOCI sort order. It will make Dynamics GP easier to work with for both users and administrators, and it will also remove some limitations on integrating products.
Dynamics GP is a client/server application. All the data is centrally stored in Microsoft SQL Server databases (and, optionally, some shared files on the network) and the SQL Server must be running and accessible to all client machines running Dynamics GP. The Dynamics GP application itself does not need to be installed or running on a server and administrative functions can be performed from any client machine where the application is installed.
Microsoft Dynamics GP is written in a proprietary application development environment called Dexterity. Over the years there have been many questions raised about when Dynamics GP will be rewritten in a different language. There was even an announcement about 12 years ago that Dynamics GP 7.0 would be rewritten in C#. The reality is that Dexterity is here to stay. While implementation and day-to-day operation of Dynamics GP does not require any knowledge of Dexterity, it is important to understand the terminology and structure of the Dexterity environment.
Dexterity is a 32-bit environment with a number of components that work together:
Application Dictionaries: These are files with the extension of
.dicthat store code and resources. Resources are objects such as tables, windows, and reports.Runtime Engine: This combines and interprets code and resources in application dictionaries to result in a functioning user application.
Dexterity Dictionary (
Dex.dic): This includes resources used by the runtime engine to translate the application dictionaries.
In any installation of Dynamics GP, you will find multiple products. Products can be installed and used independently even though they may integrate with other products. Typically, each Dynamics GP module will be a separate product. The major exception to this is the Microsoft Dynamics GP product, which includes most of the core Dynamics GP modules.
Each product has the following unique characteristics and components:
|
Component |
Example |
|---|---|
|
Product Name |
Microsoft Dynamics GP |
|
Product Number |
0 |
|
Product Dictionary |
|
|
Forms (or Windows) Dictionary |
|
|
Reports Dictionary |
|
A Window in Dexterity is an actual screen used in the application to enter or view data. A Form is a combination of windows, menus, and other resources that work together. For example, the About Microsoft Dynamics GP form shown in the following screenshot has two windows: About Microsoft Dynamics GP and Microsoft Dynamics GP Options. Together these two windows make up the About Microsoft Dynamics GP form.
The product dictionary contains all the core forms and reports for each product. If there are no modifications to windows or reports, the forms and reports dictionary files will not exist. If the forms or reports dictionary is found, the Dynamics GP application will look to them first when opening a modified window or report. This allows any modifications made to windows and reports to supersede the out-of-the-box code, while keeping the original product dictionary intact.
In a typical Dynamics GP installation, the product dictionary is installed locally on each workstation. The forms and reports dictionaries can be installed either locally on each workstation or located on a network share, accessible by all workstations. For implementations with no modifications to the out-of-the-box windows or reports, it is recommended to install all the dictionary files locally for improved performance.
Report Writer and Modifier are tools that allow reports and windows in Dynamics GP to be modified.
Report Writer is a Dexterity reporting tool that is included with the Dynamics GP System Manager. With Report Writer, you can modify existing reports or create new custom reports. In a standard Dynamics GP installation, there are over 800 Report Writer reports. Typical modifications to reports include adding a company logo, changing the alignment of reports to fit a pre-printed form (for example, for payables checks), and removing or adding columns on reports. Modified reports for the Microsoft Dynamics GP product are stored in the Reports.dic file.
Modifier is a Dexterity tool for customizing the appearance and behavior of Dynamics GP windows. With the new Perpetual Licensing for Dynamics GP 2013, Modifier is included with the Starter Pack purchase. Typical modifications to windows include making fields required, hiding fields, changing the name of field prompts (or labels), and changing the tab order of fields. Modified windows for the Microsoft Dynamics GP product are stored in the Forms.dic file.
When Dynamics GP was originally released, a financial reporting tool called Advanced Financial Analysis (AFA) was included for the General Ledger. This is a Dexterity based tool that includes some basic financial reports and allows users to modify and create financial statements such as Balance Sheets, Profit & Loss Statements, and Cash Flows.
It quickly became apparent that AFA was not a robust enough tool for many user requirements, so Great Plains Software, several years prior to Microsoft's acquisition of it, purchased FRx Software to accommodate the need for more functionality and flexibility for financial reporting. FRx Software made a financial reporting package called FRx Reporter (commonly called FRx) that works with many General Ledger packages in addition to Dynamics GP. If you have implemented previous versions of Dynamics GP, you have most likely worked with FRx, as this was the financial reporting tool of choice for Dynamics GP.
Starting with Dynamics GP 2010 a new product, called Management Reporter, was introduced by Microsoft to replace FRx. Management Reporter is now the only financial reporting package supported for Dynamics GP 2013 and licensing for Management Reporter is included in the Starter Pack. There are migration tools and guidelines available for moving from FRx to Management Reporter.
In this chapter we introduced some Dynamics GP specific terminology and concepts, and discussed the new Perpetual Licensing model and core modules. We outlined the structure of Microsoft Dynamics GP and briefly discussed how Dynamics GP and Microsoft SQL Server work together. The Dexterity system and financial reporting packages were introduced. You should now have a basic understanding of the Dynamics GP structure and terminology that will help you as you start your implementation.
In the next chapter, we will discuss how to start planning for your implementation.
