As a start to the 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 options and what they mean
How Microsoft SQL Server and Dynamics GP work together
The definitions of Dexterity and Product Dictionaries
Financial reporting choices—AFA, FRx, and Management Reporter
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. Or a module can be as narrow in scope as Customer/Vendor Consolidations, which allows you to define relationships between vendors that are also 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 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 that you own. 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 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 Dynamics GP implementation, it is important to understand what modules you own and what licensing structure you fall under. This may change some of your plans for Dynamics GP or help you identify additional purchases needed prior to implementation.
All Dynamics GP licensing is sold on a concurrent user basis—you can have an unlimited number of named 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. The concurrent logins are enforced by the application; it is not an honor system, as some applications are, relying on the users to monitor usage. The following is a matrix of the Dynamics GP licensing available:
|
License Mode |
License Edition |
Details |
|---|---|---|
|
Business Ready Licensing |
Business Essentials |
Initial purchase includes a core set of approximately 20 modules and one concurrent user. Additional concurrent users are purchased separately, there is no maximum. Only some additional modules are available for separate purchase. |
|
Advanced Management |
Initial purchase includes a core set of most of the available modules and one concurrent user. Additional concurrent users are purchased separately, there is no maximum. All additional modules are available for separate purchase. | |
|
Module Based Licensing |
Standard |
Every module and user are purchased separately. A maximum of 10 concurrent users can be purchased, this is enforced by the application. Only some additional modules are available for purchase. |
|
Professional |
Every module and user are purchased separately. No maximum for concurrent users. All modules are available for purchase. |
Module Based Licensing is no longer sold to new customers. Existing Module Based Licensing customers can upgrade to Business Ready Licensing by paying a fee. Business Essentials can be upgraded to Advanced Management, if you require modules that are not available under Business Essentials.
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 just about every Dynamics GP implementation utilizes. All of these modules are included in Business Essential licensing:
Dynamics GP System Manager: Mandatory, the System Manager is the 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 is the subledger that holds the details for all vendors and vendor transactions.
Receivables Management: Also called Accounts Receivable (AR), this is the subledger that 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 transaction 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 the following diagram:
 |
Older versions of Dynamics GP, when it was still called Great Plains, supported installation on three different database platforms: ctree, Pervasive SQL (previously called btrieve), and Microsoft SQL Server. Starting with version 8.0, Microsoft Dynamics GP is only supported on Microsoft SQL Server.
While I have not heard a single complaint about not being able to support Dynamics GP on ctree 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 at the Developing for Dynamics GP blog:
Understanding how Microsoft Dynamics GP works with Microsoft SQL Server: http://blogs.msdn.com/developingfordynamicsgp/archive/2009/05/22/understanding-how-microsoftdynamics-gp-works-with-microsoft-sql-server.aspx
Understanding how Microsoft Dynamics GP works with Microsoft SQL Server continued: http://blogs.msdn.com/developingfordynamicsgp/archive/2009/05/29/understanding-how-microsoft-dynamics-gp-works-withmicrosoft-sql-server-continued.aspx
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 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 by 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 installation of upgrades or service packs may fail if the database owner is not DYNSA.
When you install Dynamics GP, a global system database called DYNAMICS will be created. This 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 inside Dynamics GP. Active processes and logins are also held in the DYNAMICS database.
There is no limit on how many companies can be created in Dynamics GP. Every new company you create will be a new SQL Server database. The only limitation on this is for the database ID to be five characters or less and not to start with a number.
A sample company is available to be installed with sample data for many of the Dynamics GP modules. The database ID for the sample company is TWO and it is called Fabrikam. For anyone wondering about the strange database ID, in older versions of Dynamics GP the sample company was called The World Online.
Only two Microsoft SQL Server collation types are supported by Dynamics GP:
Binary—sort order 50
Dictionary Order, Case-Insensitive (DOCI)—sort order 52
The recommendation for new installations is to use a DOCI collation. It will make Dynamics GP easier to work with both for users and administrators, 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 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 10 years ago that Dynamics GP 7.0 would be rewritten in C#. The reality is that Dexterity is here to stay. While implementing Dynamics GP does not require any in-depth 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 are files with the extension of
.dicthat store code and resources. Resources are objects such as tables, windows, and reports.The Runtime Engine combines and interprets code and resources in application dictionaries to result in a functioning user application.
The Dexterity Dictionary,
Dex.dic, 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 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. When the Dynamics GP application is launched, if either the forms or reports dictionary for a product is not found, that dictionary will be recreated from the resources in the product dictionary. If the forms or reports dictionary is found, the Dynamics GP application will look to them first for any windows, reports, code, or resources. 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 preprinted 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. Modifier is not included in any core Dynamics GP licensing and is available for purchase separately with all of the Dynamics licensing options except Business Ready Business Essentials. Typical modifications to windows include making fields required, hiding fields, changing the name of fields, 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 created for the General Ledger. This is a Dexterity-based tool that includes some basic financial reports and allows users to modify and create financial reports 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 referred to as FRx) that works with many General Ledger packages in addition to Dynamics GP. If you have implemented previous versions of Dynamics GP, you would 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, has been introduced by Microsoft to replace FRx. At the time of this writing, Management Reporter does not have all the functionality of FRx and it is being slowly phased-in as more features are added. Customers that are new to Dynamics GP will automatically receive Management Reporter, but can request FRx if they need functionality that Management Reporter does not have yet.
In this chapter, we introduced some Dynamics GP specific terminology and concepts, and discussed licensing options 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 to start your implementation. In the next chapter, we will discuss how to start planning for your implementation.
