Microsoft Dynamics GP: Data Management

Exclusive offer: get 50% off this eBook here
Microsoft Dynamics GP 2010 Reporting

Microsoft Dynamics GP 2010 Reporting — Save 50%

Create and manage business reports with this Microsoft Dynamics GP 2010 Reporting book and eBook

$35.99    $18.00
by Christopher Liley | April 2011 | Enterprise Articles Microsoft

As any developer or consultant that has been tasked with filling user requests for reports is aware, ultimately the very first question after deciding on the reporting tool is "Where is my data and how do I get to it?"

In this article by Christopher Liley, author of Microsoft Dynamics GP 2010 Reporting, we will discuss the following:

  • Differences between the DYNAMICS database and company databases
  • Conventions that are helpful to know and understand when it comes to Microsoft Dynamics GP 2010 data and how it is stored
  • Using Resource Descriptions as a tool for finding data from within GP 2010
  • Utilizing additional tools, such as the GP 2010 SDK, to find our data

 

Microsoft Dynamics GP 2010 Reporting

Microsoft Dynamics GP 2010 Reporting

Create and manage business reports with Dynamics GP

        Read more about this book      

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

Knowing where to begin is a critical first step in the development process. The aim of this article is to provide helpful tips for finding and locating data in the Dynamics GP 2010 ERP system and company databases. Although we'll discuss some reporting tools that do not require us to know the SQL database structure for Dynamics GP companies, it is still helpful to understand how GP stores its data.

DYNAMICS database versus company database

The first task of identifying where our data is located is making sure we are using the correct database! Microsoft Dynamics GP 2010 utilizes the Microsoft SQL Server platform as its database engine. When Dynamics GP 2010 is installed on our environment and a new company is created, the installation process creates several databases on a server that has been designated during the install. These databases will store all the information entered through the Dynamics GP 2010 application, and we can use SQL Server Management Studio to access the underlying tables that store this data.

Microsoft Dynamics GP has two types of databases: a system database (DYNAMICS) and company database(s). For first-time report developers and seasoned writers, knowing which of these databases stores a particular piece of information we need is crucial for an accurate report.

What is the DYNAMICS database?

When Microsoft Dynamics GP is first installed and some initial settings are provided, a system database will be created. This database is the DYNAMICS database. It includes such things as records for each company that you create, the organizations registration information, the maximum account framework, and so on.

Regardless of how many company databases we have, they will all share a single DYNAMICS database.

From a reporting standpoint, there is certain information located in the system database that we may need to report on at one time or another. We have provided a quick reference for this information below:

  • Multicurrency System Setups – This includes the setup of the currencies, the exchange rates, and the currency symbols for those organizations that process transactions in any number of foreign currencies.
  • Intercompany Setup – This is where the intercompany relationships are stored and the specific due to/due from accounts are mapped.
  • Organizations Structures – This will include the organizational levels and entities that have been created for those organizations that use this feature.
  • User Master – This table stores information about the users in the ERP system, including their user ID and username.
  • User Tasks – This table stores the tasks that users set up in Dynamics GP. These are the tasks that are displayed on the users' Home screens in GP.
  • Company Master – Stores company setup information such as whether security is enabled, the company ID is in the form of the company database ID in SQL Management Studio, primary address information, tax schedule defaults, and any number of options for the company.
  • Security Setups – This includes all of the security tasks, security roles, and user security assignments.
  • User-Company Access – Includes the companies that each user has access to.

Company database

Each company that we create in Dynamics GP has its own company database. As information such as transactions, accounts, and customer or vendor data is entered through GP, this information is recorded in individual fields. These fields comprise the smallest unit of data stored. All of this data makes up a record and a record is grouped with similar records and stored in a table.

For obvious reasons, this data is segmented by company database so that each company can maintain unique records. In addition to this transactional data, numerous additional company setups exist in the company database. As with the DYNAMICS database, we may need to report on some of these company system setups. Here is a quick reference to the more common company setup tables:

  • Account Formats – Stores the chart of accounts format for the company.
  • Posting Definitions – Stores how the individual modules post to the General Ledger.
  • Company Locations – Lists additional addresses for each company.
  • Source Document Master & Audit Trail Codes – Every transaction is assigned both a source document and an audit trail code. This table can be used to report on the full description of these codes.
  • Shipping Methods Master – Stores the setup details of the shipping methods for the company.
  • Payment Terms Master – Stores the setup details of the payment terms created for the company.
  • Record Notes Master – Stores all of the record level notes for the particular company.
  • Comment Master – Stores predefined comments to be used across multiple series in Dynamics GP.
  • Electronic Funds Transfer – Stores the EFT setup information for the company for both Payables and Receivables modules. This includes customer and vendor banking information.
  • Period Setup – Stores the fiscal period setup for the company.
  • Sales/Purchases Tax Tables – These tables store the tax detail and tax schedule records as well as the tax summary amounts.

Dynamics GP table naming/numbering conventions

Dynamics GP has a rather interesting and sometimes frustrating table naming structure. When developers or consultants first see this, they are overwhelmed, to say the least. However, once you learn that there is a rhyme and reason to the madness, it actually makes a lot of sense and it is quite easy to follow and locate the tables that we need.

Tables versus table groups

When data is entered into windows via the Microsoft Dynamics GP application, that data is stored in tables in the underlying SQL database. In most cases, data entered via a single process can be stored in two or more tables. In such cases, it is common for these tables to be grouped together by a certain naming convention. For example, entering journal entry information may update the Transactions Work table (contains General Ledger transaction header information), the Transaction Amounts Work table (contains the General Ledger transaction distributions), and the Transaction Clearing Amounts Work table (contains the General Ledger clearing transactions distributions). These make up what are called Table Groups. These table groups are also referred to as logical tables.

Each Microsoft Dynamics GP table has three names: a technical name, a display name, and a physical name. The technical name is used solely by the software and will usually be seen in some alert messages instead of the display name. The display name is the name that will appear in most of the alert messages generated by the system and is typically the name used for a given table when referring to it in speech, for example, Vendor Master. The physical name is the name that will be found in the SQL database when looking in Microsoft SQL Server Management Studio.

Physical table naming/numbering conventions

When working within the context of a SQL database to generate reports, developers and consultants will make use of the table physical names. A quick scan through the various tables in a standard GP install reveals a bewildering array of table numbers. How can there possibly be any rhyme or reason to these table names? Surprisingly, it does actually follow a certain pattern. For the most part, the table numbering follows a special convention. This schema packs a lot of information into a small number, and it can help developers and consultants know where to begin looking for their data.

As Dynamics GP has grown into a more comprehensive accounting solution, it has expanded, in part, by incorporating third-party applications into the solution. While many of the third-party programmers tried to stick within the relative bounds of the GP physical table naming conventions, as we will soon see, this is not always the case. So, while many of the tables that belong to the core GP modules maintain a fairly standard numbering convention, we will find that this does not hold true for all GP modules.

Generally speaking, GP table physical names contain a two or three digit alpha prefix followed by a five digit number. The three digit prefix represents the module for which the table holds data. The numbers that follow identify what type of data is held in the table. For example, is it posted transaction data? Or, is it information related to the module setup?

As we see in the next image and following sections of this chapter, the numbering schema for a Dynamics GP physical table can be broken down to reveal information about the kind of data that is found in that table.

Microsoft Dynamics GP 2010 Reporting

Alpha code

Let's begin by taking a look at the alpha-prefix for these tables. We have put together a handy reference of some of the most common prefixes and the modules that they represent:

Prefix Module Prefix Module
AA Analytical Accounting MRP Material Requirements Planning
AF Advanced Financials MXLS Audit Trails/Electronic Signatures
ASI SmartList NLB Navigation List Builder
BM Bill of Materials (Mfg) OC Sales Configurator (Mfg)
CFM Cash Flow Management OSRC Outsourcing (Mfg)
CLM Certification Manager PA Project Accounting
CM Checkbook Master PDK Personal Data Keeper (Proj. Acct.)
CN Collections Management PM Payables Management
CP Capacity Requirements Planning (Mfg) POP Purchase Order Processing
DD Direct Deposit PP Revenue Expense Deferrals
EC Engineering Change Management (Mfg) QA Quality Assurance (Mfg)
ERB Excel Report Builder RM Receivables Management
EXT Extender RT Routings (Mfg)
FA Fixed Assets SC Sales Forecasting (Mfg)
GL General Ledger SLB SmartList Builder
HR Human Resources SOP Sales Order Processing
ICJC Job Costing (Mfg) SVC Field Service
IV Inventory SY System/Company Setup
IVC Invoicing (Sales) UPR Payroll
MC Multicurrency VAT Intrastat
ME Electronic Reconcile (EFT) WC Work Centers (Mfg)
MOP Manufacturing Order Processing WO Manufacturing Orders

In some modules, such as Manufacturing, tables are broken down even further with Routing tables represented by one set of digits while Material Requirements Planning data is found in tables represented by another set of digits. More commonly, however, entire modules are generally represented by a single alpha code, such as is the case with Project Accounting where all project transactions, billing, and revenue recognition tables are represented with the same alpha code.

Table type

Once we've identified the module in which our data might be stored, our next thought should be towards the type of data that we are trying to find. Before we return to the numbering convention, let's take a look at the various types of data that exist in GP tables:

  • Setup: Almost all modules in GP have set up windows that allow users to define default options or other settings for how that module will be used. The options selected in these windows can be found in the Setup tables.
  • Master: Some modules, such as Payables Management, allow users to record master records. These master records represent permanent records, such as vendors, for the company. Typically, master records must be entered prior to using a module, as transactions will utilize these master records.
  • Transaction: These tables contain the transaction-level data from Dynamics GP. These include the most basic of GP transactions, the journal entry, to transactions entered in sub-ledgers, such as the distribution records of a posted Receivables invoice. Transactions entered in various modules will, depending on their status, be stored in one of three types of transaction tables:
    • Work: Un-posted transactions can generally be found in work tables. The name is appropriate, as these transactions can be considered a "work-in-progress". They have not been committed to the sub or general ledgers via posting processes, so we should factor this into our thinking when deciding whether or not to include these records in our reports.
    • Open: Generally speaking, records in these tables have been posted, but are awaiting an additional action before they can be considered "closed" or "history". In the General Ledger module, the open table represents all journal entries for the current open year. In other modules, such as Receivables Management, open tables contain data for receivables transactions that have not yet been fully applied.
    • History: Transactions that are "completed" generally end up in the history tables. Again, this depends on the module. For example, in Payables Management, fully applied invoices are moved to history. In Purchase Order Processing, however, a routine exists to move completed purchase orders to history. Until this routine is run, records will not be moved to history.
  • Cross Reference: Some tables represent data that spans multiple modules. For example, GP users can link purchase orders to unfulfilled sales order line items via Sales Order Commitment. The prefix of the table that contains these links indicates that this is a Sales Order Processing table, but in actuality, it contains data from Purchase Order Processing, as well.
  • In addition to these main table types, other table types exist that are less commonly used for reporting purposes. Nonetheless, it is helpful to understand what these table types contain:
    • Report Options: Before users can generate a report from the Reports menu, a series of options must be designated for that report. These report options are recorded in a series of report options tables.
    • Temp: As the name implies, data is only stored in these tables temporarily. Temporary tables can be used in a variety of situations, such as when a user presses the "Post" button for a transaction. Although rare, it may be necessary to use a temp table when designing a report that should contain data from the time of posting. For example, a sales invoice can be generated at the time the user posts the invoice and can be based on data stored in a temp table at the time.

In terms of the physical naming convention for GP tables, the data type is represented by the first digit following the module code. The following table contains the various table types and their associated number in the numbering convention:

Table Type Number
Master 0
Work 1
Open 2
History 3
Setup 4
Temporary 5
Cross Reference 6
Report Options 7

Sequence

The next two digits in the numbering convention make up the sequence number. This number indicates the logical table to which the table belongs. As we discussed earlier in the article, logical tables are related tables, or table groups, that share similar data. Not only do these table groups share similar data, but they also share the same data type and sequence number when it comes to the physical table numbering convention.

For example, let's consider the following set of logical tables:

  • PM00200 (Vendor Master)
  • PM00201 (Vendor Master Summary)
  • PM00202 (Vendor Master Period Summary)
  • PM00203 (Vendor Accounts)
  • PM00204 (Purchasing 1099 Detail)

These tables comprise the Payables Vendor Master Logical File table group. We can easily see this by the numbers that follow the module code. First, we see that these tables share the same data type—remember, 0 means these are Master tables—and second, we see that these tables share the same sequence number. Although we need other tools to help us determine the name of the table group, we are able to easily scan through a list of table physical names in SQL Management Studio and see that these tables are in the same table group.

Variant

The final two digits of the physical numbering convention represent the logical group variant. Within a logical group, numbers are incremented sequentially. This is evident in our example using the Payables Vendor Master Logical File above; as we see the final two digits of each table increment by one.

In table groups related to transactions, the variant often distinguishes between header tables, detail tables, distribution tables, and other related tables.

Keep in mind, what we have discussed is only a general naming and numbering convention for GP tables in their SQL databases. Unfortunately, to the frustration of developers and consultants everywhere, these conventions do not hold true in all cases! At the very least, knowing this convention can point us in the right direction. We can rely on other tools and resources to help us pinpoint the right table when these conventions fall short.

 

Microsoft Dynamics GP 2010 Reporting Create and manage business reports with this Microsoft Dynamics GP 2010 Reporting book and eBook
Published: April 2011
eBook Price: $35.99
Book Price: $59.99
See more
Select your format and quantity:

 

        Read more about this book      

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

Locating Dynamics GP data using the Resource Descriptions windows

One of the most useful tools for locating data when being tasked with writing reports against Dynamics GP data is the Resource Descriptions tool within the application itself. Resource Descriptions are broken into three distinct windows: Tables, Windows, and Fields. Typically, we find ourselves using a combination of these three windows to locate the specific data we are looking for. There is not really a right or a wrong way to use these windows. Each report developer or consultant could argue that the way he or she uses the windows is the correct way, but ultimately, as long as we are able to identify and find the data we need, we will be that much closer to creating an accurate report that fills our users' needs.

The various Resource Descriptions windows are located by browsing to Microsoft Dynamics GP | Tools | Resource Descriptions.

Tables

Table Descriptions let us select a Product (Microsoft Dynamics GP, Fixed Assets, and so on) as well as the Series (Financial, Sales, and so on). We are then provided a list of all the tables for the selected product and series. By default, the list of tables is by Display Name. We do have the option to change how the tables are sorted by changing the View By field. The options are Table Display Name, Table Group Technical Name, Table Physical Name, or Table Technical Name. The method we choose will depend on how familiar we are with the table structure. For example, we might select Table Physical Name once we are familiar with the naming convention guidelines provided earlier in this chapter. There is also a Find button that allows us to search for the table based on any one of its three names.

To access Table Descriptions follow these steps:

  1. Open Microsoft Dynamics GP.
  2. Click the Microsoft Dynamics GP Menu from the toolbar.
  3. Select Tools.
  4. Select Resource Descriptions.
  5. Select Tables.
  6. Click the Ellipses button and find your table. In the image below, we are searching for the PM Vendor Master File table, which is found under the Microsoft Dynamics GP Product and Purchasing Series.

Microsoft Dynamics GP 2010 Reporting

Once we have found the table we are looking for, we can drill into that table and get additional information for that table. This view includes all of the fields in the selected table, their physical names (as would be seen in the SQL tables), the storage type of the field, and the position.

We can access this additional information by double clicking the table record in the Table Names window. This opens a new window called Table Descriptions:

Microsoft Dynamics GP 2010 Reporting

From the Table Descriptions window, we can further drill into each field and get information such as the Format Type, the Keyable Length of the field and if applicable, any Static Values if it is a dropdown field.

We can access this detail by double clicking a field or selecting the field and clicking the Field Info button to open the Additional Field Information window:

Microsoft Dynamics GP 2010 Reporting

Returning to the Table Descriptions window, the last pieces of information we can access from this window are additional info such as any secondary tables, the secondary tables' keys, what the related fields are for the tables, and what the relationship type is. We can also see the usage, which gives us all the forms and reports that use this table.

Most of this information can be found by returning to the Table Descriptions window and clicking the Additional Info button. This opens the Additional Table Information window as seen in the following image:

Microsoft Dynamics GP 2010 Reporting

Also, from the Table Descriptions window, we can access the Table Usage window by clicking the Usage button on the Table Descriptions window:

Microsoft Dynamics GP 2010 Reporting

Typically, we use Table Descriptions when we know the name of the table needed and we need to find additional information about that table.

Fields

Field Descriptions gives us the ability to again select both the Product and the Core (Series), which contains the field we are looking for. Once both these fields are selected, we are provided with the field list. Similar to how we could look at field info in Table Descriptions, we can look at field info here as well.

To access Field Descriptions, follow these steps:

  1. Open Microsoft Dynamics GP.
  2. Click the Microsoft Dynamics GP Menu from the toolbar.
  3. Select Tools.
  4. Select Resource Descriptions.
  5. Select Fields.
  6. Select a Product and a Core.

For example, in the following image, Microsoft Dynamics GP has been selected as the Product and System has been selected as the Core value. This shows us a list of fields that meet this criteria and a list of the tables that contain the selected field:

Microsoft Dynamics GP 2010 Reporting

The one added benefit of using this window over others accessible via Resource Descriptions is that once we select the field we are looking for, a list will be provided showing us all the tables that contain that field.

This window is typically used when we are not sure exactly which table(s) a requested field resides in. We can use this window to tell us all the table display names that contain the selected field, then we can go to Table Descriptions and find the physical (SQL) table name based on results returned in the Field Descriptions window.

Windows

Windows Descriptions provides us with the ability to view the windows where the data is being recorded or viewed. As with the other Resource Description windows, we select the Product and Series. Once we locate the window we are looking for, Purchase Order Entry for example, we will be provided a list of both the fields on that window and the tables used by the window. We can also use the Form name in this window to find the related fields and tables.

To access Window Descriptions, follow these steps:

  1. Open Microsoft Dynamics GP.
  2. Click the Microsoft Dynamics GP Menu from the toolbar.
  3. Select Tools.
  4. Select Resource Descriptions.
  5. Select Windows.
  6. Select a Product, Series, and View By from their dropdown lists.

As the following image shows, selecting Microsoft Dynamics GP as the Product, Purchasing as the Series, and by Window Display Name as the View By option presents us with a list of all windows available in this unique combination:

Microsoft Dynamics GP 2010 Reporting

We typically use Window Descriptions when we know where the requested information is being entered or displayed in Dynamics GP, but we are unsure of the field name(s) or the table name(s) used to store said data. As with Field Descriptions, once we have a list of possibilities, we can cross reference to Table Descriptions.

This window is a bit constrained in size, and when dealing with a Product and Series with numerous tables, it can often be time-consuming to scroll through the list to find the right window. Don't neglect the Find button in the upper-right hand corner of this window. After selecting this button to open the Find window, we can type in the Display Name we are looking for and the window will auto-focus on this row in the scrolling window. Remember, the Display Name corresponds to the name of the window as it appears in the menu bar attached at the top of the window in GP. Of course, this requires knowing and selecting the Product and Series to which the window actually belongs prior to opening the Find window.

Table Import

Another very useful resource for finding the data that we need to begin writing our reports is the Table Import utility. From any window in Dynamics GP, we can open the table import utility and be provided with all the friendly table display names that are used by this window. For example, opening the Table Import window from the Sales Transaction Entry window yields the following information:

Microsoft Dynamics GP 2010 Reporting

To access the Table Import from any window, follow these steps:

  1. Open Microsoft Dynamics GP.
  2. Open the Dynamics GP Window you are looking for.
  3. Select Tools.
  4. Select Integrate.
  5. Select Table Import.

Once we know which table we want to go find our data in, we can again cross reference the Table Resource descriptions to find the physical SQL table name. This utility is very useful if the user tells you that they need a report that includes information they are entering on a particular screen.

Accessing data at the table level using SQL Management Studio

Once we have identified our physical table name, we can begin to use SQL Management Studio to view the data in the table. To accomplish this, we can write simple select statements to view the data. This can be very useful, as it allows us to see actual data in the underlying table. So, if a user tells us they need information they are entering in Sales User defined fields, we can view that data directly in the table to be sure we are capturing the requested data. A helpful tip for this is to open the Sales User-Defined Fields Entry window in Dynamics GP for a specific document number. Then, in SQL Management Studio, we can select the record from the table (in this case, the SOP10106 table) that equals the same document number we are looking at in the screen. This allows us to ensure we are looking at the correct data.

One thing to keep in mind if we are working on a production database or even a test database with large amounts of data is that we can use commands such as NOLOCK, TOP 1, TOP 10, etc. to keep us from putting inadvertent locks on the table and to limit the amount of data returned by our queries. We don't necessarily need to select all records from a Sales Transaction table to see the data in that table and begin writing our report. It is much more efficient to use small selections of data at this point in our data gathering.

A sample of these TSQL statements can be seen in the following image:

Microsoft Dynamics GP 2010 Reporting

In SQL Management Studio, there is another very useful command that we have at our disposal. This command is called SP help and is very easy to use. We simply open a new query window and type in sp_help and our table name (sp_help SOP10100). This will return information such as the owner of the table and the created data, along with all of the columns in the table, their names, types, whether they are computed, their length, and if they are nullable amongst other things. We will also be provided with the indexes on the table. All of this information can be helpful to us when we begin writing our reports.

Locating Dynamics GP data with additional tools

Earlier in this article, we discussed a logical way for finding data for our report by starting at the database level and working our way down to the field level within the SQL database tables. While this approach utilized the GP naming and numbering convention, as well as the Resource Descriptions and Table Import tools within Dynamics GP, several other tools exist outside of the standard GP application that can help us better understand where our data might be located.

Dynamics GP 2010 Software Development Kit

Another useful tool for report writers and developers to use when trying to determine which tables should be used in building a report is the Software Development Kit or SDK, for short. Unlike the Resource Description windows, this tool resides outside of Dynamics GP and requires a separate download, meaning that you don't need a workstation installation of Dynamics GP to use this tool.

Downloading the Software Development Kit

New releases of the SDK are timed to coincide with new releases of the Dynamics GP application. The 2010 version of the SDK was released around the same time as Dynamics GP 2010. Microsoft Partners and customers can find the download under the Product Releases section of PartnerSource and CustomerSource, respectively. Additionally, the SDK can be installed from the original Dynamics GP 2010 CD software.

On PartnerSource, however, several SDKs exist, many of which contain information related to additional products and tools that can be integrated with the core Dynamics GP application. For example, users can find SDKs for Business Portal 5.0 for GP 2010 as well as for eConnect for GP 2010 on the same Product Releases page. Our focus will be on the SDK designed for the core application, which is labeled on the Product Release page as the "Software Development Kit (SDK) for Microsoft Dynamics GP 2010".

After downloading the file, extract the contents and run the executable to begin the SDK installation. Accepting defaults will install the program so that it can be opened from the Microsoft Dynamics folder under the Start menu.

Using the Software Development Kit

The Software Development Kit (SDK) is broken up into several sections containing information related to customizing Dynamics GP 2010 and working with the various database objects that exist in each company's SQL database. Among these sections, we will find the following:

  • Table Integration, Database Diagrams: This section provides diagrams of tables related to the selected module. While information about specific fields is not found in this diagram, this documentation can be helpful in displaying a list of tables related to a specific module.
  • Table Integration, Design Documents, and Transaction Flows: Documents in this section describe how data flows from one table to the next as transactions are conducted in GP.
  • Additional Products: Additional modules, such as Manufacturing and Project Accounting, are not included with the information described in the preceding sections. Check this section to find documentation describing the tables and fields related to these modules.

We can use the SDK when we want to get a better understanding of how data flows through the various tables. Data in GP flows through many SQL tables as transactions are conducted in the overlying GP application. Often, we are asked to develop reports that capture data at a certain point in the transactional process, and we can use the SDK to help us determine where to locate this data.

Summary

In this article, we discussed the various challenges of developing reports. Once those challenges have been considered, the next step is finding our data. Even though some reporting tools do not require understanding the SQL database structure of GP company databases, we can still use our knowledge of GP data structures to build better reports.

To that end, we've used this article to explore some of the conventions surrounding how GP data is stored. We began at the database level by exploring the differences between the DYNAMICS database and the various company databases. Then, we moved on to understanding the naming and numbering convention for tables found within these databases. At first glance, the numbering convention used for GP tables can be confusing, but by this point, we are familiar with some general naming conventions that can help us in most cases.

Finally, we looked at some tools that can be used for finding this data. Some tools, such as Table Resources, Table Import, and SQL stored procedures can be used with any standard install of GP.


Further resources on this subject:


Microsoft Dynamics GP 2010 Reporting Create and manage business reports with this Microsoft Dynamics GP 2010 Reporting book and eBook
Published: April 2011
eBook Price: $35.99
Book Price: $59.99
See more
Select your format and quantity:

About the Author :


Christopher Liley

Chris Liley is a Principal Consultant with Microsoft Partner I.B.I.S., Inc.in Norcross, GA and a Microsoft Certified Information Technology Professional for Dynamics GP.  He is a graduate of Georgia State University with a B.B.A in Accounting.  Chris has worked with Dynamics GP since 2001.

Chris’ experience ranges from financial analysis, software implementations, data conversions, integrations to designing and developing customizations in both the functional and technical area of consulting for Dynamics GP.  Chris also has extensive experience designing Business Intelligence solutions.

Books From Packt


Microsoft Dynamics GP 2010 Implementation
Microsoft Dynamics GP 2010 Implementation

Microsoft Dynamics GP 2010 Cookbook
Microsoft Dynamics GP 2010 Cookbook

Microsoft Dynamics Sure Step 2010
Microsoft Dynamics Sure Step 2010

Microsoft Dynamics NAV Administration
Microsoft Dynamics NAV Administration

Microsoft Dynamics AX 2009 Administration
Microsoft Dynamics AX 2009 Administration

Microsoft Dynamics NAV 2009 Programming Cookbook
Microsoft Dynamics NAV 2009 Programming Cookbook

Microsoft Dynamics NAV 2009 Application Design
Microsoft Dynamics NAV 2009 Application Design

Implementing Microsoft Dynamics NAV 2009
Implementing Microsoft Dynamics NAV 2009


Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software