Microsoft Product Support

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg
Showing posts with label Architecture. Show all posts
Showing posts with label Architecture. Show all posts

Tuesday, 8 May 2012

Theresa Nistler talks Microsoft Dynamics GP 2013 Features

Posted on 09:02 by Unknown
Theresa Nistler, Sr. Program Manager with the Microsoft Dynamics GP team, explains the balancing act of defining features and incorporating those into the application. Theresa also works hand to hand with the Support teams to compile feedback from clients aand resolve bugs.



Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Read More
Posted in Architecture, Dynamics GP 12 | No comments

Tuesday, 1 May 2012

Brian Meier talks Microsoft Dynamics GP Business Analyzer

Posted on 12:27 by Unknown
Business Analyzer is one of those products that I really dig: it's slick, it works, and it just makes life easier for executives and information consumers who don't necessarily need access to GP... but if they do, Business Analyzer also lives within GP, with some pretty cool context sensitivity, based on the info displayed by a specific item or items within a Navigation List object.

Brian Meier, Sr. Lead Program Manager at Microsoft, explains his role and provides an inside look at Business Analyzer.



Related Articles:

Kevin Racer talks Microsoft Dynamics GP 2013 Architecture
Chad Sogge describes the features process for Microsoft Dynamics GP 2013

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Read More
Posted in Architecture, Dynamics GP 12, Dynamics GP 2010 R2 | No comments

Wednesday, 18 April 2012

Kevin Racer talks Microsoft Dynamics GP 2013 Architecture

Posted on 13:32 by Unknown
A few days aback it was Chad Sogge describing the features process for Microsoft Dynamics GP 2013. Now is Kevin Racer talking Microsoft Dynamics GP 2013 architecture and the toolset sorrounding it. Take a look at this short video describing it all:



Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Read More
Posted in Architecture, Dynamics GP 12 | No comments

Wednesday, 23 November 2011

Codename GP "12" Preliminary Features Series - Wrap Up

Posted on 04:00 by Unknown
Over the past few days I have presented some of the product enhancements being considered and developed for codename GP "12". Those enhancements are based on 4 core pillars: Simplicity, Productivity, Product Depth, and Innovation.

As we approach the Microsoft Convergence 2012 event, I am sure more of these will be revealed.

As is customary, you can find links to all previously published articles:

Codename GP "12" Preliminary Features Series - 1 of 4
Codename GP "12" Preliminary Features Series - 2 of 4
Codename GP "12" Preliminary Features Series - 3 of 4
Codename GP "12" Preliminary Features Series - 4 of 4

I encourage you to continue following the Inside Microsoft Dynamics GP blog by the Microsoft Dynamics GP Product Management Team. They are the premier (and official) source for information on all things codename GP "12" and if you have been to the site, you will know that closer to the product release date, you will get a "Feature of the Day" post showcasing new functionality.

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Read More
Posted in Architecture, Dynamics GP 12, Roadmap | No comments

Tuesday, 22 November 2011

Codename GP "12" Preliminary Features Series - 4 of 4

Posted on 04:00 by Unknown
Codename GP "12" Preliminary Features - Part 4 

This is article is part 4 of 4 from the series Codename GP "12" Preliminary Features. Some images and content reproduced with express permission from Microsoft Business Solutions, a division of Microsoft Corporation.

DISCLAIMER: These features are subject to change.

In part 3 of the series, we discussed the different enhancements geared towards building up the Microsoft Dynamics GP product depth: enhancements to the GL year-end process, ability to generate Fixed Assets historical reports, and tolerance handling in the purchasing receipt process, are just among the few that stand out.

Of course, the Innovation pillar is mostly dominated by the release of the Web Client, but I will have to add some of the other features that got cataloged in the Product Depth pillar as true product innovations, even though the technologies supporting these innovations has been around for quite sometime.

Product Depth? More like Innovation

If the dynamic conversion of all Dexterity based forms is not an innovation, then I don't know what else qualifies. Take a look at my previous articles on the subject:

Microsoft Dynamics GP "12" Web Client Architecture - Part 2
Microsoft Dynamics GP "12" Web Client Architecture - Part 3

For the complete series on the Web Client, please take a look at my series:

Microsoft Dynamics GP "12" Web Client Architecture Series

To learn more about the Multitenant Services capabilities coming to GP "12", please take a look at my article:

Microsoft Dynamics GP "12" Multitenant Service Architecture

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Read More
Posted in Architecture, Dynamics GP 12, Multitenancy, Roadmap, Web Client, Web Services | No comments

Friday, 18 November 2011

Codename GP "12" Preliminary Features Series - 2 of 4

Posted on 04:00 by Unknown
Codename GP "12" Preliminary Features - Part 2 

This is article is part 2 of 4 from the series Codename GP "12" Preliminary Features. Some images and content reproduced with express permission from Microsoft Business Solutions, a division of Microsoft Corporation.

DISCLAIMER: These features are subject to change.

Yesterday, in Part 1 of the Series we saw some of the new features in the Simplicity pillar: Select printer at Print Time, improvements in the Fixed Assets calendar setup process, reprinting of check remittances, and the ability to print SSRS reports directly from within Microsoft Dynamics GP, in what seems to be a race to replace Report Writer reports.

Today, we will take a look at some of the features in the Productivity pillar, whose aim is to "enhance productivity from application configuration to frequently performed tasks".

Productivity Features

System Enhancements

Among the features being worked, the Named System Database and Multi-tenant Applications are two of the most important features aimed to change Microsoft Dynamics GP architecture. I have covered these two features extensively in my Microsoft Dynamics Communities column articles:

Microsoft Dynamics GP "12" Named System Database Architecture
Microsoft Dynamics GP "12" Multitenant Service Architecture

Bank Reconciliation Enhancements

In the Bank Reconciliation front, you can expect the new Sub Ledger Reconcile BR to GL feature. If you are worried about your checkbook balance and GL cash account not matching, this new option will present you with reason for the out of balance conditions: a batch not posted, a voided GL entry, etc. This new feature also looks at the Receivables and Payables module.

By adding the checkbook ID as a field, you can compare the checkbook balance to the Cash Account in GL. This new reconcile tool will attempt to match records on transaction source, date, and amount and will report matched transactions, unmatched transactions, and potentially matched transactions, with the capability to drill back to the document and/or journal entry.

You can then save the output file and date when the reconciliation was performed so you don’t need to run the reconcile again. This option has been retrofitted to the other reconciliation processes.

Fixed Assets Enhancements

Yesterday I talked about the Fixed Assets Calendar Setup enhancements. You can expect other enhancements in the Fixed Assets GL Posting process – you will now be able to create batches of fixed assets transaction. As with every other batch in the system, you will now be able to review what is going to post to GL before it is posted, via an edit list.

You can build the batch, insert restrictions - today, you are only able to enter a date range and Fixed Assets pulls everything - such as dates, transaction type (depreciation, transfer, retire, addition) review the batch, make changes, and post. You can post in detail vs. post in summary - the only option available today. Going forward, each distribution line in Fixed Assets will have an equivalent distribution line in GL.

Other enhancements in Fixed assets will entail Mass Depreciation Reversal. This one is much needed as, if you have depreciated 1,000 assets through the end of the year by mistake, you would have to manually back out each of the 1,000 assets. In GP "12", you will be able to perform a mass reversal of the depreciation - all assets at once.

EFT Enhancements

EFT Payables and Receivables will see the introduction of the Bank Administration Institute (BAI). The process will use the current Configurator to setup an EFT file based on BAI standards.

Distribution Enhancements

Purchasing Receivings will now see Tolerance Levels handling for quantities being received. If you setup a tolerance level, any quantities not received within the tolerance limits will automatically be cancelled on the Purchase Order. You will have the option to setup whether you want to do this automatically or prompted.

SOP and POP Drop Ship for Serial/Lots items – GP "12" will allow you to track serial/lot numbers from vendors. Users will have the ability to enter the serial numbers for any product being drop-shipped, unlike current released versions of GP. If you have a SOP invoice linked to a PO then the Serial/Lot will come across onto the SOP invoice.

As you can see, there are tons of enhancements in all of the above modules. GP "12" is geared towards solving some of the complexities in business processes that were a bit neglected in current releases.

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Read More
Posted in Architecture, Bank Reconciliation, Dynamics GP 12, EFT, Fixed Assets, Roadmap, Sales Order Processing | No comments

Monday, 20 June 2011

Microsoft Dynamics GP "12" Multi-tenant Services Architecture

Posted on 08:55 by Unknown
Finally, my new post on Microsoft Dynamics GP "12" Multi-tenant Services Architecture has been released on the Community site under my In My Humble Opinion column. After much debating with my buddy Aaron Donat (thanks Aaron for your patience!) on the previous article I released under the same title, it was deemed that that article should have been changed to reflect the Named System Databases architecture change that the Development team in Fargo was working on.

This new article highlights the changes that the Microsoft Dynamics GP web client, web services, eConnect, and Integration Manager will undergo to support various customer deployments under one single application instance. Now, this is true optimization! Hosting partners rejoice!

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Read More
Posted in Architecture, Dynamics GP 12, eConnect, Integration Manager, Web Services | No comments

Monday, 6 June 2011

Microsoft Dynamics GP "12" Architecture: Correction!

Posted on 11:36 by Unknown
In past days I released an article explaining the upcoming Named Systems Database architecture enhancement in codename GP "12" release. However, this article was incorrectly released under the title Microsoft Dynamics GP "12" Multi-tenancy Architecture. The article's title, content, and graphics have been corrected since and re-released under the title Microsoft Dynamics GP "12" Named System Database Architecture under my Community site column, IMHO with The Dynamics GP Blogster.

For your convenience, the link remains the same and your bookmarks should continue to work. To compensate for this mishap, I have also included additional information on the Named System Database feature and the problems it's trying to solve.

The Multitenacy Architecture concept is still very much alive and I will pick this up in an upcoming article. Please stay tune as you will sure like this one!

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Read More
Posted in Architecture, Dynamics GP 12 | No comments

Monday, 23 May 2011

Microsoft Dynamics GP "12" Named System Database Architecture

Posted on 08:28 by Unknown
I received a lot of feedback from the community as a whole on the 3-part series of articles on Microsoft Dynamics GP "12" Web Client Architecture and I was pleased to know that many of you are embracing the fact that there will be a Web client version of the product and are asking numerous questions about readiness.

While these articles addressed the client portion of the solution, I really did not mention anything about changes in the database architecture and how these will impact the future deployment options. So, I have released a new architecture article on Microsoft Dynamics Community, this time addressing Microsoft Dynamics GP "12" Named System Database Architecture.

In this article I look at the named system database capabilities to be released in GP "12". This is, the ability to set any name to the traditional, hardcoded DYNAMICS database. Hope you enjoy the article and if you have any comments or questions please feel free to post back.

For convenience sake, I will be adding a new link to the architecture series.

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/

Edits:

06/06/2011 - Changed article title to fit instructions provided by Microsoft Escalation team and current developments out of Fargo.
Read More
Posted in Architecture, Dynamics GP 12, SQL Server | No comments

Monday, 16 May 2011

Microsoft Dynamics GP "12" Web Client Architecture - Part 3

Posted on 04:00 by Unknown
This is article 3 of 3 from the series Microsoft Dynamics GP "12" Web Client Architecture. Some images and content reproduced with express permission from Microsoft Business Solutions, a division of Microsoft Corporation.

In Part 2 we explored the Microsoft Dynamics GP "12" Web Client's Rendering Engine and how it had to be decoupled from the overall Dexterity Runtime Engine functions, in order to create a Generic Window Object that could be rendered as a Windows Form or a Silverlight interface.

Today this article discusses how a Generic Window Object is transformed into a Windows form or a Silverlight UI, but before, let's remember that the Window Manager, a former part of the Dexterity Runtime Engine, is still in charge of processing the UI events while  the Rendering Engine presents the interface to the end-user.


Dynamic Form Rendering with Template Processor

Now that the Dexterity Runtime Engine has been freed of these tasks, the resulting Generic Window Object must be processed to produce either interfaces. For this, the Development team has created Template Processor.

Template Processor takes a generic representation of a window and is able to deliver an XML version of its content (fields, buttons, and events in the case of a traditional Dexterity window), called a Window Template, but as well delivers a version that the Dexterity Runtime Engine can still display in the classical client, also known as coreTemplate. The technique of processing a Generic Window Object into an XML Window Tempalte and a coreTemplate has been labeled Dynamics Form Rendering.

The XML Window Template is then delivered to Silverlight via a browser application - explicitly Internet Explorer given the use of Silverlight - where the Rendering Engine uses a Converter to serialize into a Silverlight UI. Since the Dexterity Runtime Engine retains the ability to understand the coreTemplate elements, displaying a Windows form is still a natural function.

Dynamic Form Rendering - Developer's Experience

The result will still allow developers to create traditional Dexterity customizations against the classic client UI or the XML Window Template generated by the Template Processor.

On a closing note, GP "12" aims to provide additional deployment methods to the traditional classical client deployment, where the client is either delivered as an installation at desktop level or in a Terminal Server or Citrix environment. With the Silverlight client, users can rely on their Internet Explorer browser and the Silverlight plug-in to run their Microsoft Dynamics GP application, while retaining the feature rich functionality of the classical client.

To make things even more interesting, a deployment environment can take advantage of both the classical client and the Silverlight client at the same time. Why would you need both? I suspect certain application functions like maintenance are best executed from the classical client, however in the scheme of things, it allows for a smooth end-user transition.

Finally, I hope you enjoyed this series of articles and I will continue to work with the Microsoft Dynamics GP Product Management team to deliver information to you as it becomes available (and needless to say, not deemed a trade secret). There is more to all this than meet the eyes.

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Read More
Posted in Architecture, Dexterity, Dynamics GP 12, Roadmap, Web Client | No comments

Wednesday, 11 May 2011

Microsoft Dynamics GP "12" Web Client Architecture - Part 2

Posted on 04:00 by Unknown
This is article 2 of 3 from the series Microsoft Dynamics GP "12" Web Client Architecture. Some images and content reproduced with express permission from Microsoft Business Solutions, a division of Microsoft Corporation.

In Part 1 of this series I went through the architecture transition from the classic client (the traditional Microsoft Dexterity interface and its evolution) to the Microsoft Dynamics GP "12" Web Client and introduced some elements of that architecture (Silverlight, .NET C#, and .NET Runtime) and how these elements fall into the "Built to Last" philosophy outlined in the overall Architectural Foundation.

Today, this article will continue down the lines outlining some of the technology challenges posed by the introduction of the Web Client and the highlighting some of the radical changes (from a development perspective) needed at the core of Microsoft Dexterity and Microsoft Dynamics GP to enable the Microsoft Silverlight interface.

The Rendering Engine

If you are a Microsoft Dexterity developer, you are already in tune with the purpose of forms (windows in the general sense) as an essential part of any Microsoft Dexterity application or integrating solution. After all, there are a key mechanism by which a user will interact with the Microsoft Dynamics GP system.

As such, a Microsoft Dexterity window typically includes sanScript code associated to the controls on that window. This code executes in response to events given the intended function of the window and the controls, i.e., save a transaction, post a batch, etc., under the direction of the Script Interpreter.

Note: The process of chunking a dictionary typically involves the removal of source code for shipping of the dictionary. Hence the need for the Script Interpreter as an integral component of the Runtime Engine.

Under the hood though, the user interface is administered by the Window Manager, which in turn talks to the Rendering Engine to display the actual Microsoft Dexterity window on the screen with the control elements previously laid out by the developer.

Web Client Architecture
The tight bond between UI and code has served well up to now, but it hasn't been without its drawbacks. One of the biggest complaints registered by developers and users alike is the fact that too much of the Microsoft Dynamics GP code resides within the user interface and the confines of the dictionary which makes for a heavy client - nonetheless, fitting the traditional client/server application architecture.

To facilitate the transition to the Web Client, the Window Manager and Rendering Engine have been decoupled from the functions of the Runtime Engine, allowing the Microsoft Dexterity Runtime Engine to produce a Generic Window Object instead. With a generic window, a classic client can continue to serve up the typical Win32 forms all the while allowing a Silverlight client to serve up a web based representation of that form. Decoupling the Window Manager and Rendering Engine allows for forms to move freely between the Win32 and Web worlds with the help of another key piece of technology - more on this in the next installment.

With the Window Manager and Rendering Engine decoupled, you can now conclude that a Microsoft Dexterity application can run as a service in the background, awaiting for events that would be either received via a traditional Win32 form or a Silverlight client, and STILL be able to execute script events regardless of the type of form they were submitted through. The theory also would indicate that a Microsoft Dexterity application is the basis for a Web Client version of itself. This is, a Microsoft Dexterity applications can leverage the new architecture elements to become web enabled - but not the other way around (yet!).

But how is the classic UI transformed into a web version? In the next and final installment, I will dig a bit more into the patent worthy elements of the architecture: Template Processor and Dynamic Window Rendering.

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Read More
Posted in Architecture, Dexterity, Dynamics GP 12, Roadmap, Web Client | No comments

Monday, 9 May 2011

Microsoft Dynamics GP "12" Web Client Architecture - Part 1

Posted on 07:35 by Unknown
This is article 1 of 3 from the series Microsoft Dynamics GP "12" Web Client Architecture. Some images and content reproduced with express permission from Microsoft Business Solutions, a division of Microsoft Corporation.


In past weeks I mentioned expanding a bit more on the Web Client to be introduced with codename GP "12".

Web Client Overview

The Web Client is the full GP application delivered through the Web. The key pieces to be delivered will be the core application components, ISV dictionaries, and in-house customizations - Dexterity customizations. At the core of the web client is the UI update which will feature new homepage tiles, ribbons and tabs. Microsoft expects that UI performance will rival that of Terminal Server or better.

Client/Server Architecture Transition

Historically, the Microsoft Dynamics GP application has followed a 2-tier client/server architecture, which divides the application functions into two distinct, but very interrelated components: the database server and the client application.

The database server, which relies on Microsoft SQL Server, hosts the system and company data, along with extended business logic that allows it to process some of the heavier operations that would be extremely time consuming to perform at the client, for example, transaction posting business logic.

In turn, the Microsoft Dynamics GP client application, built on Microsoft Dexterity, has always performed the functions of delivering the user interface, providing data entry validation, and rendering reports - ok, so it does a bit more at times, but in context these are the key functions.

Transition from current Client/Server architecture to the Web Client architecture
A Microsoft Dexterity application is divided into two distinct elements: 1) a Runtime Engine that deals with the technology aspects of the application environment, like communicating to the operating system and establishing and managing the connection to the databases, and 2) a dictionary which hosts all the core application components and business logic, such as the forms, reports, and the sanScript code that makes the entire user interface and reports do something in response to user commands and input.

This architecture has been time tested and has served its purpose even after numerous technology changes over the years. In fact, application users have seen no disruption to the application functionality due to technology changes. The same could be said for changes in functionality- see Microsoft Dynamics GP Architectural Foundation Series with Tim Brookins for a primer on GP's architecture.

The Web Client, built on Microsoft Silverlight delivers a set of components and services oriented toward the UI and user interaction, including user input, lightweight UI controls for use in Web applications (some other Silverlight features that probably won't be a part of the Web Client include media playback, digital rights management, data binding, and presentation features, including vector graphics, text, animation, and images). Also Silverlight includes the Extensible Application Markup Language (XAML) for specifying layout which is heavily used by the Web Client.

The Silverlight Web Client application uses a subset of the .NET Framework that contains components and libraries, including data integration, extensible Windows controls, networking, base class libraries, garbage collection, and the common language runtime (CLR). The development language of choice, of course, is C#.

Some parts of the .NET Framework for Silverlight are deployed with the Web Client application. These "Silverlight Libraries" are assemblies not included in the Silverlight runtime and are instead shipped in the Silverlight SDK. The Silverlight Libraries used by the Web Client, are packaged up with the application and downloaded to the browser from the Server. These include new UI controls, XLINQ, Syndication (RSS/Atom), XML serialization, and the dynamic language runtime (DLR). Perhaps, not all these elements will make it to the initial release of the Web Client, but will gradually make their way in the future.

For more on Silverlight architecture click here.

Tomorrow, I will cover in more detail some of the changes required in the current architecture (from a technology stand point) to be able to serve up the Silverlight UI.

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Read More
Posted in Architecture, Dexterity, Dynamics GP 12, Roadmap, Web Client | No comments

Microsoft Dynamics GP "12" Web Client Architecture Series

Posted on 07:30 by Unknown
You've got a peek at the past Microsoft Dynamics GP Technical Conference, you saw it at Microsoft Dynamics Convergence Atlanta 2011. But do you really understand what goes on "under the hood". If you are intreagued by the upcoming codename GP "12", today I begin a series of articles oriented to shed some light on the new application architecture. Get a review of the web client and the transition from the classic client to the new architecture environment, understand what changes went into rendering the Silverlight interface, how UI templates work and future deployment options, get an introduction to Dynamic Form Rendering and why this technology is so cool.

The publishing schedule for these articles are as follows:

Published DateFeatured Article
05/09/2011Microsoft Dynamics GP "12" Web Client Architecture - Part 1
05/11/2011Microsoft Dynamics GP "12" Web Client Architecture - Part 2
05/16/2011Microsoft Dynamics GP "12" Web Client Architecture - Part 3
05/23/2011Microsoft Dynamics GP "12" Named System Database Architecture 

Disclaimer: Some images and content reproduced with express permission from Microsoft Business Solutions, a division of Microsoft Corporation. The content of these articles should not be reproduced without permission from this author.

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/

Edits:
05/23/2011 - Added link to Named System Database Architecture article on Dynamics Community.
Read More
Posted in Architecture, Dexterity, Dynamics GP 12, Roadmap, Web Client | No comments

Friday, 10 September 2010

What are all those GPSFOINTEGRATIONID columns in some tables

Posted on 08:49 by Unknown
I thought I would close the week with a very little known fact to new comers (and some not so new) to the Microsoft Dynamics GP world.

First some history

Around mid 1998 (or so), Siebel Systems formed an alliance with the then Great Plains Software Inc. to deliver a suite of front- and back-office applications. Great Plains' back-office applications included an integrated suite of accounting, financial, and supply chain modules. Under the agreement the new suite would add Siebel's front-office applications covering sales, marketing, and e-business functionality. The combination would allow users to complete sales transactions over the Web, for instance. Great Plains delivered the first component of its new package in November 1999 as the Sales and Marketing Series of Great Plains Siebel Front Office, with customer service and call-center applications to follow in 2000. The suite was aimed at small and mid-sized businesses.

The new Great Plains Siebel Front Office product would initially offer a module to automate sales, marketing, service and electronic business processes. With another module for customer service following in January of 2000, this was the first step toward overall front office/back office solutions.

Fast-forward to April of 2001, Microsoft completed its acquisition of Great Plains and soon began working on other plans to phase out GPSFO, pushing overall its .NET technology and its vision for a .NET based CRM solution. As a result, Microsoft CRM 1.0 was released in January of 2003... the rest is, well, history!

So, how is history related to the title of this post?

So now that you know that your beloved Microsoft Dynamics GP used to play some serious game with Siebel, it's just about right that they had to have some way of talking back to each other, this is, integration.

As an integration mechanism between GPSFO and Great Plains Dynamics, the Dynamics dictionary (DYNAMICS.DIC) went through a few changes required to accomodate integration points between the two systems. Today, there are still vestiges of these changes in the SOP10100 (Sales Transaction Work), SOP10200 (Sales Transaction Amounts Work), RM00101 (RM Customer Master), RM00102 (RM Customer Address Master) tables. These tables all share a GPSFOINTEGRATIONID, INTEGRATIONID, and INTEGRATIONSOURCE columns, used to track and exchange information between GPSFO and Dynamics. Even the Field Service module had piece of the action with the SVC00203 (Service Call Line Detail) and the SVC_FO_ID column.

Now, can I reuse those columns to store my own data?

As the say goes, not because you can means you should. While these columns are no longer used to store data in these tables -- according to the Microsoft Dynamics GP SDK they are marked as "reserved" -- you should not begin to store your own data in them. Microsoft may choose in the future to re-purpose or simply drop these from the database schema and your data will be gone. Hence, it's not recommended to use these fields for any purpose. Alternatively, you can create your own custom tables, whether in Dexterity or natively in Microsoft SQL Server to store any related sales information.

As a final request, please add your comments on your experiences (or nightmares, depending who you ask) with GPSFO. Let's see how many of you veterans are still out there and tackled the "new brave world" (or the 'old' as it has been a good number of years since).

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/
Read More
Posted in Architecture, Article, CRM, Receivables Management, Sales Order Processing | No comments

Monday, 19 July 2010

Microsoft Dynamics GP 2010 Architecture Whitepaper available for download

Posted on 04:30 by Unknown
Microsoft Dynamics GP 2010 Architecture Whitepaper is now available for download from Microsoft Download Center. Architecture is something dear to my heart so please be sure to download this document and read up. The document discusses the following topics:

  • The structure of the Microsoft Dynamics GP application, which is composed of the Dexterity runtime engine, the Dynamics application dictionary, and the Microsoft SQL Server database.

  • How Microsoft Dynamics GP efficiently uses system resources for both client workstations and servers.

  • The customization tools that are built into the software and are accessible to all users, and the tools that system administrators can use to customize Microsoft Dynamics GP, such as Modifier, Report Writer, and Visual Basic for Applications (VBA).

  • The tools that are available for importing and exporting Microsoft Dynamics GP data, such as eConnect, Web Services, and Integration Manager.

  • The features that provide platform enhancements, such as flexible account numbers, lists, data-driven scrolling windows, security, international support, macro capabilities, named printers, the mail API, and error reporting.

  • The reporting and analytics tools that are available for Microsoft Dynamics GP, including Report Writer, SmartList, Management Reporter, SQL Reporting Services, and Excel Reports

  • How the workflow capabilities in Microsoft Dynamics GP control the flow of documents through the accounting system

  • The architecture and features of Business Portal, which you can use as your company intranet or as an extension to it to provide Web-based access to Microsoft Dynamics GP data.

  • The additional industry- or market-specific capabilities that are included with Microsoft Dynamics GP, such as multidictionary architecture, the trigger system, and available development options.
Hope you find this whitepaper useful and certainly a gem to have in your product documentation arsenal.

Related Articles

Microsoft Dynamics GP Architectural Foundations Series - featuring Microsoft's Tim Brookins

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/
Read More
Posted in Architecture, Dynamics GP 11, Dynamics GP 2010 | No comments

Wednesday, 14 July 2010

DYNSA

Posted on 15:32 by Unknown
There are a number of good blog posts in the community explaining the differences between sa, Microsoft SQL Server's defacto administrative user; and DYNSA, Microsoft Dynamics GP defacto administrative user. In reading a number of these articles I realized one thing: they address little about the DYNSA user.

So what's DYNSA?

You only have to read back a few lines to obtain this answer, however, I want take another direction. Let's start by saying that in Microsoft SQL Server, every database is created with a dbo user. Take for example this blank database created using SQL Server Management Studio:



The dbo is a user that has implied permissions to perform all activities in the database. Any member of the sysadmin fixed server role (like sa for example) who uses a database is mapped to the special user inside each database called dbo. Also, any object created by any member of the sysadmin fixed server role belongs to dbo automatically.

For example, if user DYNSA is a member of the sysadmin fixed server role and creates a table RM00101, RM00101 belongs to dbo and is qualified as dbo.RM00101, not as DYNSA.RM00101. Conversely, if DYNSA is not a member of the sysadmin fixed server role but is a member only of the db_owner fixed database role and creates a table RM00101, RM00101 belongs to DYNSA and is qualified as DYNSA.RM00101. The table belongs to DYNSA because he did not qualify the table as dbo.RM00101... and hear is the catch! Because DYNSA is not created as a member of the sysadmin fixed role (otherwise we would have a lot of angry database administrators), it must be associated to fixed database role db_owner, hence all object creation operations performed from Dynamics Utilities must qualify the object creation preceeded by "dbo.".

The dbo user cannot be deleted and is always present in every database.

Only objects created by members of the sysadmin fixed server role (or by the dbo user) belong to dbo. Objects created by any other user who is not also a member of the sysadmin fixed server role (including members of the db_owner fixed database role):

•Belong to the user creating the object, not dbo.

•Are qualified with the name of the user who created the object.

This explains two things:

1) Only sa can perform the first time installation of Microsoft Dynamics GP, since this is when all databases, database objects, and the DYNSA user are created. During installation, DYNSA is made a member of the db_owner fixed database role.

2) In lieu of the sa user, Microsoft Dynamics GP system administrators can use DYNSA to perform any upgrade or maintenance activities. Since DYNSA is the defacto database owner, then it can perform any activities related to that database. This is the reason why you should ensure that DYNSA remains the database owner prior to initiating any upgrade activity. The following script should help with this:


1. Run the following making sure that DYNSA is the database owner:


sp_helpdb DYNAMICS;
go
sp_helpdb %COMPDB%;
go


2. If the above returns anything different than DYNSA, use the following script to set the database owner to DYNSA:


use DYNAMICS;
go
sp_changedbowner 'DYNSA';
go
use %COMPDB%;
go
sp_chagedbowner 'DYNSA';


In the above scripts, replace %COMPDB% for your company database name on SQL Server.

Related Articles:

Microsoft Dynamics GP 10 POWERUSER role vs Microsoft SQL Server sysadmin role

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/
Read More
Posted in Architecture, Code, Installation, Security, SQL Scripting, SQL Server, Troubleshooting | No comments

Tuesday, 13 April 2010

Microsoft Dynamics GP Architectural Foundations Series - Insight Featuring Tim Brookins

Posted on 05:01 by Unknown
This is article 7 of 7 from the series Microsoft Dynamics GP Architectural Foundations Series - featuring Microsoft's Tim Brookins.

Unfortunately and due to Tim's various commitments, it was not possible to have him provide his final insight on the white paper reproduced on this blog. I will continue to work behind the scenes to bring this information to you as it becomes available.

For now, I leave you with a review of Tim's background and accomplishments.









About Tim Brookins


Tim Brookins is a Distinguished Engineer working in the Microsoft Entertainment & Devices Division.

Tim joined Microsoft in 2001 as part of the Great Plains Software acquisition and has 20 years of experience in the business applications space. At Great Plains he was instrumental in producing the company's first offering based on Microsoft SQL Server. Brookins also designed the model-driven architecture that enables products from multiple parties to merge seamlessly into a single solution without source code changes. These innovations formed the technical foundation for the successful Great Plains partner ecosystem. In 1997, Brookins was named the first “Technical Fellow" at Great Plains in recognition of his contributions.

After joining Microsoft, Brookins worked for two years in the Developer Division as part of the Microsoft Visual Studio team. He researched CLR-based, model-driven business frameworks with a focus on advanced customization via model extensibility and managed programming models.

Tim is currently working on the Windows Mobile team, contributing to the company’s Windows phone efforts.

He is based at the Microsoft facility in Fargo, N.D. Brookins spends his time interacting with co-workers in Redmond, Wash., and the Microsoft European Development Center in Copenhagen, Denmark, as an advocate of distributed development.

Brookins holds bachelor’s and master’s of science degrees in electrical engineering from North Dakota State University.






Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/
Read More
Posted in Architecture, Article, Roadmap | No comments

Sunday, 11 April 2010

Microsoft Dynamics GP Architectural Foundations Series - Conclusion

Posted on 05:00 by Unknown
This is article 6 of 7 from the series Microsoft Dynamics GP Architectural Foundations Series - featuring Microsoft's Tim Brookins.

Tim's whitepaper was originally published in 1999 and it's reproduced here with his permission.









Conclusion

A typical architecture white paper will usually babble on about the popular technologies of the day like Client/Server, SQL Server, Thin Clients, Browser Clients, Stored Procedures, FRx, Office Integration, Report Writing, 2-Tier, 3-Tier, ODBC, Internet, Transact SQL, Windows NT, etc.

This document operates at a more strategic level, primarily because the endless list of technologies are changing constantly. In short, technologies come and go, but architectures are built for the long term. Any meaningful discussion of product architecture must be based on principals or philosophies that are technology independent.

The eEnterprise product architecture is based on a single fundamental premise, with four supporting philosophies:

The value of the business management system is contained in the Business Logic.

• The business logic must be Built to Last
• The business logic must be Built to Grow
• The business logic must be Built to Leverage
• The business logic must be Built to Fit

This document has been dedicated to describing these philosophies in detail. When a specific technology like C++ or VBA has been mentioned, it is only an example of how current technologies are being used to support these long-term philosophies.

While I've tried to avoid mentioning specific technologies in order to focus on the long-term architecture, keep in mind that eEnterprise is the industry leader in technology support. Client/Server, SQL Server, Thin Clients, Browser Clients, Stored Procedures, FRx, Office Integration, Report Writing, 2-Tier, 3-Tier, ODBC, Internet, Transact SQL, Windows NT... Yes, eEnterprise supports them all!

But in the end, never allow a laundry list of technologies from any vendor cloud your vision. Always keep in mind that today's "must have" technologies will quickly become tomorrow's "must replace" technologies. Great technology is not enough. Great functionality is not enough. You need a product that has an established track record of sustained technology and functionality leadership that only a superior architecture can deliver. I hope you'll agree the eEnterprise architecture has the solid foundations you can trust to take your business into the future.





In the next article Tim Brookins offers his insight.


Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/
Read More
Posted in Architecture, Article, Roadmap | No comments

Monday, 5 April 2010

Microsoft Dynamics GP Architectural Foundations Series - Built to Fit

Posted on 05:00 by Unknown
This is article 5 of 7 from the series Microsoft Dynamics GP Architectural Foundations Series - featuring Microsoft's Tim Brookins.

Tim's whitepaper was originally published in 1999 and it's reproduced here with his permission.







Built to Fit

Buyers in the midmarket require more than shrink-wrapped applications. It is imperative the system fit seamlessly into the customer’s overall business. The overall fit of the software is determined in two principal ways: customization and integration.

No matter how feature-rich a business management system, each customer will have unique needs not covered in the basic software. The Dynamics architecture must accommodate significant product customization as a basic part of the system. Additionally, the customized business management application must be integrated with all the other applications in the business.

The Dynamics architecture must also recognize that “Built to Fit” must not interfere with the “Built to Grow” philosophy. The process of customization and integration cannot modify the product in such a way that future upgrades are economically impossible. “Built to Fit” must work in a manner that allows cost-effective product upgrades.

Product Customization: What is VBA?

To understand the role of VBA in product customization, let’s begin with Visual Basic. Microsoft Visual Basic is one of the world’s most widely used rapid application development (RAD) environments. It is estimated over three million programmers know how to produce applications in the Visual Basic environment.

Visual Basic produces new, standalone applications. This does not meet the need for product customization. To enable customizations, we would need a special version of Visual Basic which, instead of producing new standalone applications, could “embed” itself inside an existing application. This special version of Visual Basic would allow customizations of the existing application without modifying source code.

It’s important the customizations are accomplished without modifying source code, because this greatly simplifies loading new versions of the business management system during upgrades. If the customization modifies source code, it becomes too expensive to reapply those changes to the new version. This defeats “Built to Grow.”

Microsoft Visual Basic for Applications (VBA) is designed to meet this need. Microsoft VBA is a special version of Visual Basic that can be embedded inside another application. VBA is included as part of the Office suite, and is the primary way end users customize Excel or Word.

In addition to the Microsoft Office products, Microsoft has allowed a select group of software vendors to license this technology. Some common names you might recognize are AutoDesk (AutoCad), Seagate Software (Crystal Reports), Adobe, Micrographix, Visio, and Cognos.

Visual Basic: Good or Evil?

At this point you may be confused. I spent significant time earlier in this document discussing Visual Basic’s weaknesses relative to C++. In this section, I am proudly proclaiming our support for this great Visual Basic technology, VBA. So is Visual Basic good or evil? The answer is both, and I intend to prove this is not just my opinion. Microsoft itself has come to the same conclusion.

The role of VBA in Microsoft Office

The diagram below depicts the role of VBA in the Office product. In the lower left, you see the block labeled “C++.” This demonstrates that Microsoft chose C++ as their base development environment for the Office products (Excel in this specific case). The block in the upper left communicates that the business logic and user interface of Excel is based on C++ code.

Note that the portion of the diagram to the left of the line represents the Microsoft “Internal” tools used to build Excel itself. To the right of the line represents the tools “External” users (i.e., end users) use to customize Excel.

This “Internal” vs. “External” differentiation is key to understanding the role of Visual Basic in Microsoft products. We can see Microsoft believed C++ was the best language to construct Excel. However, just because Microsoft chose C++ for its internal use doesn’t mean C++ was the best choice for external users. C++ is a powerful language, but it is complex and requires some intense training. As a RAD tool, Visual Basic is a much better environment for the public at large. Therefore, Microsoft chose to expose VBA as the primary customization tool for Office.

So is Visual Basic good or evil in this case? It’s clear Microsoft does not consider Visual Basic to be a good choice to build a complex commercial application. However, it is an excellent choice for allowing end users to easily customize the C++ built application.



The Role of Visual Basic in Dynamics

The diagram shown below should look very familiar. The role of Visual Basic in the Dynamics architecture is basically identical to the Office strategy.

The lower left quadrant indicates our choice of C++ as our primary development language. However, like Microsoft, just because we chose C++ as our internal language to build Dynamics doesn’t mean C++ is the best language for external users to customize Dynamics. For external purposes, we choose to support Visual Basic for Applications.

This is the perfect opportunity to deal with some other misconceptions other vendors may have about Dynamics. In some cases, you may hear: “Great Plains added VBA support to their latest release. They recognize Dexterity was a mistake, and VBA is just the first step of throwing out Dexterity and rewriting their whole application in Visual Basic.”

You should now have enough understanding of our (and Microsoft’s) strategies in this area to see how ludicrous this statement is. Because our strategies are identical, try substituting Excel into the same argument just for fun: “Microsoft added VBA support to the latest release of Excel. They recognize C++ was a mistake, and VBA is just the first step of throwing out C++ and rewriting the whole application (Excel) in Visual Basic.”

Of course, neither Microsoft nor Great Plains has any intention of moving away from C++ to Visual Basic as its primary development environment.

So is Visual Basic good or evil? As I promised, it’s both. We believe C++ is a great choice for building large, complex, high-performing commercial applications.We also believe Visual Basic is a great choice as a customization tool. When the roles are reversed, both products become “evil.” C++ would be a terrible choice for customization, and Visual Basic would be a terrible choice for internal development.



Will the real VBA please stand up?

Visual Basic has become a common customization tool for most business management software vendors. Several major business software vendors have released customization products based on some form of Visual Basic-like product. However, it’s imperative buyers understand these products vary widely in their level of Visual Basic support. There are three primary Visual Basic-like products in use today:


    Visual Basic for Applications
    VBA provides all the components needed to customize an application. The project window displays the objects you can customize. The property window displays object properties. You can leverage the MS Forms designer to add new windows, and then add ActiveX controls. Top this off with the full Visual Basic debugger and you get a powerful customization solution.














    Visual Basic Script
    Visual Basic Script is Microsoft’s solution for adding scripting to an application. You get the ability to write code (script), but there are few additional features. For example, there is no MS Forms support for adding windows, no ActiveX control palette, no project or property windows, and only limited debugging.















    Mystic River SBL
    SBL is a Visual Basic-clone product produced by a company called Mystic River Software. This product has a simple Visual Basic-like syntax in its scripting engine, but otherwise bears no resemblance to “real” Visual Basic. Programmers used to the modern Visual Basic environment won’t be familiar with this environment, since there is no forms support, a very basic editor, little or no debugging, no ActiveX control support, and limited COM support.













VBA: Separating the best from the rest
Now that we’ve reviewed the various products used in business management system customization, you are positioned to make an informed assessment of vendor capabilities in this area. However, be advised that vendors using other technologies will use the terms “Visual Basic,” “VBA,” or “VBA-compatible,” even if they are using proprietary, non-Microsoft products like SBL (which has no real Visual Basic code at all).

If a vendor tells you they are using VBA, be sure VBA is actually available in a shipping version of their software. Many financial management software vendors have licensed VBA from Microsoft (by paying a fee), but few are actually shipping software containing VBA. You may be wondering why Great Plains was the first vendor to ship VBA. There are two reasons for this. First, our “Built to Last” architecture allows us to quickly plug in new technologies like VBA without rewriting our business logic. Second, recall the previous section of this document entitled: “C++ vs. Visual Basic: Technology Support.” We discussed how C++ based applications are able to integrate new technologies quicker than products written in Visual Basic.

If you are wondering whether a vendor supports “real” VBA or not, simply ask for a demo. First open VBA inside Excel or Word (just hit Alt+F11 from inside either application and VBA will open). Compare the VBA environment from Office with the vendor’s version of VBA. You will be able to tell at a glance if the vendor’s VBA is the same as the real VBA in Office. Take a moment to look at the Dynamics VBA screenshot on the previous page: it looks just like VBA in Office because it is the very same application.

For an 18-page VBA white paper that describes Great Plains’ implementation of VBA in detail, we invite you to visit the Great Plains DynamicTools web page at www.greatplains.com/documents/downloads/vba_wp.pdf.stub. [Ed: Link Broken]

Built to Fit: Integration

Recall there were two components in the “Built to Fit” architectural value: customization and integration. We’ve covered customization in detail with our discussion of VBA, so we now turn our attention to integration.

Midmarket customers demand tight integration between their business management system and other parts of their business. For example, consider a business that has a custom-written order processing system that must integrate with the business management system’s receivables module.

To discuss our integration architecture, we’ll use a common framework that breaks down an application into three major components: User Interface, Business Logic, and Database.

Integrating at the database level

Integrating applications at the database level has become a very common approach. As the diagram shows, data is moved directly into the business management system’s database using integration standards such as Open Database Connectivity. This gives applications written in Access, Visual Basic, and PowerBuilder easy, standard ways of integrating at a data level. The Dynamics Import Utility also allows easy access to Dynamics tables:



There are some definite advantages to integrating at the database level (it’s typically very fast), but there are also some drawbacks. First, the end user must understand the structure of the database schema. There are usually hundreds of tables in a typical midmarket business management solution database. Compounding matters, a single “logical” document (like a receivables transaction) may need to be imported into several tables.

A second drawback to database level integration is once you have learned the datamodel and implemented your integration, the datamodel may change during a product upgrade. This is an impediment to product upgrade and goes against our “Built to Grow” philosophy.

Integration at the Business Logic level

To better support our “Built to Fit” and “Built to Grow” values, Great Plains introduces a second type of integration product: one that integrates at the business logic level. Called the Dynamics Integration Manager, this tool allows external systems to be quickly and easily integrated into the business management system.



Because the Integration Manager interacts with the business logic of the Dynamics application, no knowledge of the Dynamics database structure is required. Users simply point the Integration Manager to their external data via a graphical point and click interface, and the data is automatically imported into the business management system.

Any upgrade concerns are also eliminated with this product. Unlike database level integrations, which are susceptible to changes in table structure during a product upgrade, the Integration Manager never fails. When a new version of Dynamics is released, a new version of the Integration Manager is also released which automatically “knows” where to put the external data.

The Integration Manager contains a number of other invaluable features. For example, it is very common for external systems to use a different numbering scheme for identifiers like Account Numbers, Customer IDs, or Inventory Item IDs. The Dynamics Integration Manager can maintain translation tables and automatically translate the IDs during data imports.

Another useful feature is data synchronization. It is common for records like Customers to be tracked in more than one system. The Integration Manager allows these multiply defined resources to be synchronized. For example, if a customer address changes in an external system, that change can be automatically propagated into the Dynamics’ customer record.

In summary, the Dynamics Integration Manager is a key component of our “Built to Fit” architectural value. It allows nearly effortless integration of external data sources that will maintain their functionality across product upgrades.



You can download the original 18-page VBA white paper referenced in this article here.

In the next article Tim presents his "Conclusion".


Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/
Read More
Posted in Architecture, Article, Integration, Integration Manager, Roadmap, VBA | No comments

Friday, 2 April 2010

Microsoft Dynamics GP Architectural Foundations Series - Built to Leverage

Posted on 05:00 by Unknown
This is article 4 of 7 from the series Microsoft Dynamics GP Architectural Foundations Series - featuring Microsoft's Tim Brookins.

Tim's whitepaper was originally published in 1999 and it's reproduced here with his permission.







Built to Leverage

The previous two philosophies (“Built to Last” and “Built to Grow”) have ensured a feature-rich business management system that is ever growing. Each release builds upon the previous release, adding new functionality and technology. As functionality builds, the Dynamics product becomes a true asset to the business.

Our architecture needs to recognize the incredible value of this business asset and allow the business software engine to be used not only by Dynamics, but also
throughout the enterprise. As you will see, this is not a new idea. In fact, it’s been a goal of our architecture since the very beginning.

The diagram below shows the Dynamics’ business logic (the asset) in the large central box. The box on top labeled “Dynamics” represents the basic Dynamics user
interface. Of course, the standard Dynamics user interface leverages the Dynamics business logic to accomplish the required processing.

The whole “Built to Leverage” value is centered on expanding this usage of the Dynamics business logic to other non-Dynamics sources. The boxes labeled “Solution Developer” on the top are a great place to start. Since the first release of Dynamics, our toolset has allowed other applications to leverage the Dynamics business logic. For example, Solution Developer-produced vertical application could call the Dynamics posting routines. For the first release back in 1993, those Solution Developer products had to be written in our C++-based toolset (Dexterity). While this was a great start, we had a vision to extend this same ability to leverage the business logic of Dynamics to other non-Dexterity-based applications.

The box labeled “Continuum” on the left side is an example of how we’re delivering on this vision today. Our Continuum series of products allows an application written in any COM-compliant development environment to leverage the Dynamics’ business logic.

Our “Built to Leverage” architectural value has also allowed us to gain strategic advantage in the area of the Internet. For example, our support for electronic
commerce is enabled by allowing Microsoft Site Server to leverage Dynamics’business logic by exposing those business objects via COM. As we move into the future, additional components of the Dynamics business logic will be exposed to the Internet as Microsoft Transaction Server-based COM objects.





In the next article Tim reviews "Built to Fit".

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/
Read More
Posted in Architecture, Article, Roadmap | No comments
Older Posts Home
Subscribe to: Posts (Atom)

Popular Posts

  • The Dynamics GP Blogster's best articles of 2012
    It's that time of the year again! Time to say goodbye to the outgoing year, 2012, and receive the new one, 2013, making all sort of reso...
  • What's new in Microsoft Dexterity 11.0
    The excitement around Microsoft Dynamics GP 2010 could not be any higher. Traffic on my site has doubled since I began releasing informatio...
  • Vote for your 2012 GPUG All Star
    The time has come again to vote for the next year's GPUG All Star awards. Surprisingly, I have been nominated to this award along with f...
  • Running Windows 8.x Business Analyzer app on a laptop with SQL Reporting Services
    If you are a consultant, chances are you run your Microsoft Dynamics GP application demo environment on a laptop along with Microsoft SQL Se...
  • How to add a "Cover Letter" page to a Microsoft Dynamics GP Word Template document
    I wrote an article almost a year ago showing a simple technique to add a  Terms and Conditions page to a Microsoft Dynamics GP Word Templat...
  • "Unable to access SnapIn config data Store" accessing Web Management Console
    For quite some time I had been running into this error when attempting to access the Microsoft Dynamics GP 2013 Web Management Console appl...
  • Adding more comment lines to POP Purchase Orders
    Just recently, I was asked by a customer to address an issue with their line item comments truncating at 4 lines. In essence, the customer w...
  • Brian Meier talks Microsoft Dynamics GP Business Analyzer
    Business Analyzer is one of those products that I really dig: it's slick, it works, and it just makes life easier for executives and inf...
  • Microsoft SQL Server performance boosting settings for Microsoft Dynamics GP - Part 1
    Part 1 of 2 - Microsoft SQL Server performance boosting settings for Microsoft Dynamics GP. Disclaimer: this is not a "one-size-fits-al...
  • Resetting GP desktop position and size with the Support Debugging Tool
    Just recently I worked on an issue being experienced by several Microsoft Dynamics GP users in a Citrix environment. The users would report ...

Categories

  • Ad Campaigns
  • ADO
  • Adobe Acrobat
  • Analytical Accounting
  • Architecture
  • Around the Blogosphere
  • Article
  • Azure
  • Bank Reconciliation
  • Best of 2009
  • Best of Series
  • Best Practices
  • Bing Maps Enterprise
  • Books
  • Business Alerts
  • Business Analyzer
  • C#
  • Code
  • COM
  • Community
  • Compliance
  • Connect
  • Continuum
  • Convergence
  • Corporate Performance Management
  • CRM
  • Database Maintenance Utility
  • Decisions Conference
  • DEX.INI
  • DEXSQL
  • Dexterity
  • Discussions
  • Drill-Down Builder
  • Dynamics GP 10
  • Dynamics GP 11
  • Dynamics GP 12
  • Dynamics GP 2010
  • Dynamics GP 2010 R2
  • Dynamics GP 2013
  • eConnect
  • EFT
  • Electronic Banking
  • Encumbrance
  • Events
  • Extender
  • Field Services
  • Fixed Assets
  • Forecaster
  • From the Newsgroups
  • FRx
  • Functionality
  • General Ledger
  • GPUG
  • Home Page
  • Human Resources
  • Humor
  • IMHO
  • Installation
  • Integration
  • Integration Manager
  • Internet Explorer
  • Inventory
  • Kinnect
  • Maintenance
  • Management Reporter
  • Manufacturing
  • Menus for Visual Studio Tools
  • Microsoft Office
  • Modifier
  • Multicurrency Management
  • Multitenancy
  • MVP Summit
  • MVPs
  • Named Printers
  • Navigation Pane
  • Notes
  • ODBC
  • Office Web Components
  • OLE Container
  • Online Services
  • OpenXML
  • Partner Connections
  • Payables Management
  • Payroll
  • Performance
  • PO Commitments
  • Printer Compatibility
  • Product Feedback
  • Project Accounting
  • Purchasing
  • Receivables Management
  • RemoteApp
  • Report Writer
  • Reporting
  • Roadmap
  • SafePay
  • Sales Order Processing
  • Season Greetings
  • Security
  • Service Call Management
  • SharePoint
  • SmartList and SmartList Builder
  • SQL Reporting Services
  • SQL Scripting
  • SQL Server
  • Support Debugging Tool
  • Tax Updates
  • Technical Conference
  • The Partner Event
  • The Technology Corner
  • Training
  • Translation
  • Troubleshooting
  • Upgrades
  • VAT
  • VB.NET
  • VBA
  • VBScript
  • Visual Studio 2008
  • Visual Studio Tools
  • Web Client
  • Web Services
  • Windows 7
  • Windows 8
  • Word Templates
  • XBox
  • XBRL

Blog Archive

  • ▼  2013 (68)
    • ▼  December (2)
      • Visual Studio Tools for Microsoft Dynamics GP 2013...
      • Web Client Wednesday: Microsoft Dynamics GP on Azure
    • ►  November (8)
    • ►  October (5)
    • ►  September (5)
    • ►  August (3)
    • ►  July (8)
    • ►  June (5)
    • ►  May (5)
    • ►  April (2)
    • ►  March (11)
    • ►  February (6)
    • ►  January (8)
  • ►  2012 (101)
    • ►  December (8)
    • ►  November (6)
    • ►  October (15)
    • ►  September (16)
    • ►  August (9)
    • ►  July (4)
    • ►  June (4)
    • ►  May (6)
    • ►  April (4)
    • ►  March (11)
    • ►  February (4)
    • ►  January (14)
  • ►  2011 (158)
    • ►  December (7)
    • ►  November (17)
    • ►  October (7)
    • ►  September (8)
    • ►  August (8)
    • ►  July (12)
    • ►  June (12)
    • ►  May (13)
    • ►  April (23)
    • ►  March (21)
    • ►  February (10)
    • ►  January (20)
  • ►  2010 (168)
    • ►  December (15)
    • ►  November (11)
    • ►  October (12)
    • ►  September (24)
    • ►  August (13)
    • ►  July (12)
    • ►  June (8)
    • ►  May (17)
    • ►  April (14)
    • ►  March (9)
    • ►  February (16)
    • ►  January (17)
  • ►  2009 (5)
    • ►  December (5)
Powered by Blogger.

About Me

Unknown
View my complete profile