Microsoft Dynamics GP Architectural Foundations Series - Introduction

This is article 1 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.

---

Microsoft Dynamics GP Architectural Foundations Series

Introduction

Business managers have an overwhelming challenge in evaluating new business management systems. Even a minimal evaluation of product functionality and technology can be a huge undertaking. However, as Chief Architect at Great Plains, I urge you to expand your evaluation past the basics of functionality and technology into the area of product architecture.

Product architecture describes how the various pieces of the business system are assembled and integrated with each other. You may be wondering: “Why should I care how the business management system is designed?” Architecture is important to your evaluation because a product with a solid architecture will move gracefully into the future, while a product with a poor architecture will be unable to move forward with advances in functionality or technology.

This document addresses not only the important area of product architecture, but also describes the basic foundations and philosophies of the architecture. In other words, we describe why the Dynamics architecture was constructed in its current form.

The importance of these three areas (existing functionality and technology, product architecture, and philosophies of the architecture) can best be described by way of analogy. Instead of buying a business management system, consider an example where your business was acquiring another company. Of course, you would spend a great deal of time studying the other company’s current sales, profitability, and general financial health. I would equate this to the basic evaluation of a business management system’s existing functionality and technology.

In addition, before the purchase you would want to examine more than the company’s existing financial health. You would want to ensure the company had the resources and organizational strength to overcome future changes in the market. Thus, I would equate the process of examining the target company’s organization to the examination of the business management system’s architecture. It is the product’s architecture that will determine its ability to react to future changes.

Finally, once you had studied the company’s existing organization you would certainly have questions about why the organization had taken its current form. Typically, a company's organization is constructed in an optimal fashion to meet its near- and long-term goals. To understand the organization, you must first understand the company’s goals. In a similar fashion, to understand why a product’s architecture takes its current form, you need to understand the goals of the architecture.


Dynamics Architectural Foundations

The Dynamics architecture has four foundational philosophies:

Built to Last

Business management systems are huge. Midrange business management systems have core functionality that takes hundreds of developers years or even decades to produce. You simply can’t afford to rewrite a business management system from scratch every few years. With this in mind, the product architecture needs to promote an environment where new technologies can be integrated into the product without “rewriting from scratch.”

This philosophy benefits customers by ensuring the products can easily respond to new technologies and business opportunities without facing obsolescence. Without this emphasis on “Built to Last,” customers may face a future of product discontinuations as the existing product is thrown away, and a new product is written from scratch.

Built to Grow

Once we have a robust product that doesn’t have to be rewritten every few years, we need to ensure the product architecture allows the product to grow, adding new functionality and technologies on every release. Product growth is fostered through a number of avenues. A quality foundation, mature development processes, and an investment in supporting systems are all enablers for system growth.

This philosophy benefits customers because it allows Great Plains to accelerate the inclusion of new functionality and technologies that improve the business success of customers.

Built to Leverage

The previous two philosophies have ensured a feature-rich business management system that won’t become obsolete prematurely. Each release builds on the previous release adding new functionality and technology. As functionality builds, the product becomes a true asset to the business. The product architecture needs to recognize the incredible value of this business asset and allow the business management engine to be used not only by the business management application, but also throughout the enterprise.

This philosophy benefits customers because it allows them to leverage the functionality of Dynamics not only within the traditional Dynamics application, but also in new presentations like web browsers. It also allows other applications to leverage the functionality of the business management system through technologies like COM, the Microsoft Component Object Model.

Built to Fit

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

No matter how feature-rich a business management system, each customer will have unique needs not covered in the basic software. A solid 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 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.

This philosophy benefits customers because it allows them to tailor the product to fit their needs, while maintaining their ability to grow their systems by upgrading at a reasonable price.

---

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


Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Read More

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

Ever wanted to understand (like in really understand) why Dexterity? or what are the reasons for a dictionary-based architecture? Ever wanted to gain an insight (as in real insight) on the philosophical principles behind Microsoft Dynamics GP? Well, I pulled out all the stops for this and went to the guy who drafted it all up and architected most of it.

Back in 1997, I was first introduced to Tim Brookins at the Certified Installation Specialists Conference held in Fargo, North Dakota. Tim presented an opening session describing the Microsoft Dynamics GP architectural foundations and later materialized this session into a whitepaper.

Tomorrow marks the begining of a 7-part series of articles based on Microsoft's Tim Brookins whitepaper Great Plains Dynamics Architectural Foundations. In advance, I would like to thank Tim for allowing me to reproduce his whitepaper, which in my personal opinion, is one of the best I have ever read on the on the subject. At the end of the series, Tim will also contribute his thoughts around the paper and update you on his current role with the Microsoft organization.

At the time of the release of the whitepaper (1999), Tim Brookins was Chief Architect and Technical Fellow at Great Plains. He was responsible for the technical designs and architecture of Dynamics. His interests (at the time) included Windows NT, COM+, C++, Java, VBA, and Microsoft SQL Server -- the picture on the article is also of him back in the days.

The following is the series schedule:

Published Date	Featured Article
03/26/2010	Introduction - Dynamics Architectural Foundations
03/29/2010	Built to Last
03/31/2010	Built to Grow
04/02/2010	Built to Leverage
04/05/2010	Built to Fit
04/11/2010	Conclusion
04/13/2010	Series Insight - Featuring Tim Brookins

Links to each article will available on the publishing date.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Read More

RW - Creating Branching Logic Fields in Report Writer

After a long hiatus from blogging, here I am again with another interesting case straight from one of my clients in Venezuela.

As much as many of you dislike Report Writer, I still have to acknowledge that it still has its benefits, especially when working with tightly integrated Dynamics GP reports. Yeah, yeah, build it in SSRS, build it in Crystal, but it's always good when you don't have to build a complex report from scratch and can leverage the built-in application functionality.

The client calls me up and asks, "how can I create a CASE...END CASE statement in Report Writer?" In other reporting systems and SmartList Builder for example, it is possible to enter simple formulas that support complex conditional branching logic, for example:


CASE X
WHEN 1 THEN 'A'
WHEN 2 THEN 'B'
WHEN 3 THEN 'C'
END CASE

While it's not as apparent in Microsoft Dynamics GP Report Writer, it is possible to support this type of conditional structures by using cascading conditional fields. To illustrate cascading conditional fields, we will work with this simple example: say your company just acquired another firm with customers in Arizona, New Mexico, and Utha and you have to send out invoices this month incorporating a greeting message for customers in those states. The message says something along these lines "XYZ welcomes its new customers in [State here]". Let's see how we can accomplish this in Report Writer.

1. First, we create inner condition -- WHEN 3 THEN.



2. Second, we create the condition leading to the inner condition



3. Finally, we create the top level condition



4. With the calculated fields in place, we may now drag the 3 of them onto the Report Layout window, then change their Visibility property to Hide When Empty. That's it! Now you have created branching logic using cascading conditional fields. May not be pretty, but sure gets the job done.



A couple things to note:

a) you can create conditional branching on different fields as well using the same technique in Report Writer, for example:


CASE X
WHEN 1 THEN
CASE Y
WHEN 'A' THEN 'Z'
WHEN 'B' THEN 'Y'
...
END CASE
WHEN 2 THEN
'Something Else'
END CASE


Needless to say, the more complex your branching logic, you may be more inclined to use something like VBA, or.. ehem.. Crystal or SSRS.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com

Read More

Moving Items out of Inventory and into Fixed Assets

I love challenging customers (and partners) to use their Microsoft Dynamics GP system in very innovative ways. I like hearing things like 'this cannot be done' or 'there isn't a way to do that'. If there is a way, trust me, I will find it! One of these ways came in the form a simple question: how would you take an item that is already in inventory and move it to Fixed Assets?

Right off the start gate, I can think of 3 different ways to do this, but the solution I like the most because of its elegance and simplicity is as follows:

1. Setup an inventory site called FA and one called VIRTUAL or I/O (typically you will already have one of these setup if you have been using Inventory Control for a while).



2. Use the In-Transit Trasfer Transactions to transfer from your warehouse to the FA site using VIRTUAL as via site. Click on the Ship button to initate the 'transfer' to a Fixed Assets. In turn, this should create and in and out to your Inventory account -- so far good!



3. Open the Receiving Transaction Entry window in GP and perform an In-transit Inventory receipt type.

4. Select the In-Transit Transfer number and select the item to be transferred to a Fixed Asset.



5. Open the Receiving Item Detail Entry window then mark the Capital Item option.



6. When you click the Capital Item checkbox, click on the expansion button (blue arrow) to open the FA PO Additional Information window to add the asset information.



7. Post the receipt.

Since the Purchase Order Processing module uses a Fixed Assets clearing account to capitalize an item, you should be fine (accounting wise) once the asset is created in FA and you run your FA GL posting routine. There you go! No need to create additional vendors or customers or perform extra gimmicks.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Read More

New Article on MSDynamicsWorld: "Support Incidents vs. Consulting Engagements"

I am back at MSDynamicsWorld with a new article looking at how Microsoft Dynamics GP support incidents may (relatively quickly) end up being consulting engagements. Please take a look at this new post as it is full with useful guidelines... it may just save you some money next time when you open that new incident.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com

Read More

New Site Features!

Dear followers,

I have been working at large on a few projects hoping to wrap things up before Convergence Atlanta where I will be presenting 2 sessions with my compadre David Musgrave. As such I have been a bit out of touch with publishing new articles.

However, I have not forgotten about you, and I am currently adding some new enhancements to The Dynamics GP Blogster site, which will make things more easy for you to find. You will now see a series of links atop of this page (new ones to come!) which will allow you to quickly find articles by subject: Modifier/VBA and SQL scripts. I am working to add a Visual Studio Tools page and a Conference Materials page.

Please stay tune and thank you for your continued readership and support.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Read More

VBA - Suppressing CTRL+Break or CTRL+C in VBA Customizations

VBA is by far one of the best customization tools available to Microsoft Dynamics GP developers and as such it is widely used across a number of production environments to deliver functionality that ranges in various degrees of complexity.

However, one of the issues with VBA -- at least until now -- is the fact that an end user can inadvertly press CTRL+Break (older keyboards) or CTRL+C and stop the execution of a script. Now imagine if that script is say, some code developed to calculate 401K contributions when payroll is ran... the results will certainly not be pretty!

With this in mind, we can use a USER32.DLL library funcion to disable user input when critical VBA code is required to be executed in a block. The following shows how to implement such code:

BlockInput function

Private Declare Function BlockInput Lib "user32" (ByVal fBlock As Long) As
Long

We can now use this function across any of our VBA customizations, as follows:

Sample Window_BeforeOpen code

Private Sub Window_BeforeOpen(OpenVisible As Boolean)
  BlockInput True
  ' All the code you need to run here
  ...
  ' MAKE SURE TO RE-ENABLE THE INPUT
  BlockInput False
End Sub

There are several applications for this code, but whatever you do, don't forget to re-enable the user input, otherwise you will end up with one dead mouse and keyboard!

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Read More