Microsoft Dynamics GP Architectural Foundations Series – Built to Grow

This is article 3 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 Grow

We began our discussion with the premise that the true value of a business management system is in the product’s functionality. Our “Built to Last” architectural value allows us to “plug in” new technologies, giving end users access to leading edge technologies while also protecting the functionality from changes in technology.

We have established an architecture that allows our product to be “Built to Last,” which allows us to turn our attention to the task of ensuring we can add new functionality to the product. We call this value “Built to Grow.” At Great Plains, we ensure our product is built to grow in three primary ways.

Solid Foundation
A software developer can’t add new functionality if they are always busy fixing the old functionality. Dynamics has exceptional product quality levels. This high-quality
product gives a solid foundation on which to base new functionality.

Best Practices
Great software doesn’t happen by accident. This is especially true for very large and technically complex software like business management systems. You can’t simply
throw hundreds of developers into a room and expect robust, high-quality software to come out.

Great software requires a comprehensive strategy from requirements gathering at the beginning to testing and product shipment at the end. With this in mind, Great Plains has a corporate commitment to promoting the best practices for software development.

Great Plains bases its process effort on the Capability Maturity Model (CMM). Pioneered by the Software Engineering Institute at Carnegie Mellon University. The Capability Maturity Model provides a framework to guide and measure software engineering improvement efforts by enabling organizations to assess their software
engineering capabilities. You can learn more about the work of the Software Engineering Institute on the CMM at http://www.sei.cmu.edu/

Supporting Systems
Established processes are a must for great software development, but a “paper process” is only the beginning. Companies must act on those best practices by investing in supporting systems. Great Plains has a long history of making these important investments. Let’s begin by taking a look at just one area where Great Plains has invested in supporting systems: testing.

Since the first day Dynamics shipped back in 1993, Great Plains has committed to test each and every product feature. Before any feature is implemented, the SQA
staff defines a paper-based test plan. This plan is then put into action by recording an automated test (called a macro). As the Dynamics product has grown over the years, the test cases have also grown. Today the testing suite has grown to more than 4,000 unique cases, all backed by automated macros.

If performed by hand, this suite of test cases would take an estimated minimum of 3,000 hours of testing time to complete, equivalent to two months of work for a 10-person team. Because we’ve recorded these tests as macros, we’ve reduced the workload by a factor of 100, to around 30 hours of machine time.

But we want to be able to test our product even faster, more often, to make the code as clean as we possibly can. In response, Great Plains has increased its investment in supporting systems to build a distributed testing environment. Before development team members go home for the evening, they indicate that their machines may be used for testing by running a small application. This application communicates with a central testing server, and the result is that hundreds of machines can be used for testing. The testing server automatically downloads the version of Dynamics to be used for testing to the team member’s machine, enabling us to run tests all night on hundreds of machines simultaneously. At 7:00 am, the tests automatically stop running, the results are uploaded to a central database, and the copy of Dynamics is deleted from the team member’s machine. This distributed testing environment allows us to test many features in Dynamics in a single evening.

You may be thinking this is nothing special. “Of course all business management system vendors fully test their software.” I can assure you this is not the case. Customers cannot simply assume their business management vendor fully tests the product. Due diligence during the product evaluation phase should absolutely include
an evaluation of the vendors’ testing methods.

When you perform this evaluation, you will be shocked to find out that some vendors have no formal testing process. The product is tested by throwing a few support
people into a room and letting them “play with the software” for a few days before the new version is released. Other vendors rely on Beta releases to customers to
ensure product quality. At best, this is the vendor making the customer test the product. In reality, most customers don’t really exercise a Beta product, and the
product is simply not tested.

Some vendors have begun to realize the disastrous consequences of releasing products that are not fully tested. These vendors are engaged in a “catch-up” phase where they are trying to retrofit automated testing into an existing product. Keep this in mind when evaluating a vendor. If they tell you, “We use automated testing,” you need to follow up and ask them how much of the product is tested with these automatic tools. In reality, many of these vendors have just started, and only a few tests are actually in use. This perspective shows what an impressive asset the 4,000 existing Dynamics macros are to the customer’s productive use of the software. It has taken a software quality assurance staff of more than 50 people working for over seven years to build this test base. During this time, the testing staff also has continued to grow to support new initiatives and technologies. Vendors who are starting from scratch today will never catch up.

---

In the next article Tim reviews “Built to Leverage“.

Until next post!

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

Microsoft Dynamics GP Architectural Foundations Series – Built to Last

This is article 2 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 Last

The paradox of functionality vs. technology

Business management systems are huge. The Dynamics product has more than 1,100 windows, 900 reports, and data stored in more than 500 tables. This robust functionality didn’t happen overnight. Several years ago, a staff of more 100 developers began work on Dynamics. The number of developers has steadily increased, and today more than 240 developers work on the product. That is a huge investment to achieve this level of functionality. This is not unique to Great Plains. In general, the most successful software vendors will be those who can build system functionality not just over years, but decades.

However, there is another equally important component in a business management system: technology. A product with great functionality will be of little value to customers if it is based on an outdated technology base.

It’s clear customers demand both functionality and technology. However, herein lies a paradox. As we’ve discussed, functionality is a valuable asset that needs to be nurtured and grown over years or even decades. Technology is very different. Technology changes constantly. In the modern world of client/server, Internet, and relational databases, the rate of technological change is rapid and accelerating every day. Today’s leading-edge technology can quickly become obsolete in only a few years.

With this paradox in mind, the single most important aspect of architecture is to reconcile these two very different, but required components. At Great Plains, we have chosen an architecture that seamlessly joins our functionality and technology while keeping them separate and distinct components.

The advantages of this architecture have been proven many times during the Dynamics product lifetime. For example, when Dynamics first shipped in 1993 the primary operating system was Windows 3.1. Of course, Windows 3.1 was a 16-bit operating system and all applications that ran in this environment were also 16-bit. Dynamics was no exception.

However, in 1994 Windows NT emerged as the first legitimate 32-bit operating system for PC’s. The customer benefits of this new environment were clear. No memory limitations, pre-emptive multitasking, threading, protected application memory space, and many other advanced features awaited customers who moved to the new 32-bit environment.

Clearly, the move from 16-bit to 32-bit software was a major technological change. The Dynamics architecture was ready for the challenge. Because all technology was separated from business logic, we were able to switch our technology level from 16-bit to 32-bit without rewriting a single piece of business logic. Great Plains Dynamics version 2.0 shipped in the summer of 1994 as a 32-bit application, years ahead of any competitor.

The transition from 16-bit to 32-bit is only on example of how the Dynamics architectural strategy of separating business logic from technology is benefiting customers. Another great example is Visual Basic for Applications (VBA). We’ll talk at length about VBA later in this paper, but for now it’s enough to understand VBA is a new technology from Microsoft that allows users to customize applications. Included as a basic part of Microsoft Office, VBA is also available to selected software developers.

By leveraging our “Built to Last” architecture, Great Plains was able to include Microsoft’s Visual Basic for Applications as part of the Dynamics product by inserting it into our technology layer. Once again, we were able to give customers the benefit of this important technology without impacting our business logic.

“Built to Rewrite”

The Great Plains strategy of separating business logic from technology may seem like an obvious strategy that every vendor would pursue. I can assure you this is not the case. Time and time again other vendors have pursued a strategy I call “Built to Rewrite.” Under this strategy, these components are allowed to freely intermix.

This results in disastrous product issues. Even the relatively straightforward task of converting software to 32-bit is an insurmountable obstacle for some. Many business applications developers are still struggling to get their customers the benefits of 32-bit software. Their intermixing of technology and business logic is forcing them to rewrite significant portions of their business logic to include a “new” technology like 32-bit.

Commonality between business management systems

All business management systems can be roughly categorized into three levels: base development environment, vendor-supplied toolsets, and business logic. At the lowest level, software vendors must choose a development environment on which to base their product. Examples of commonly used development environments would be Microsoft Visual C++ or Microsoft Visual Basic. However, no vendor finds the basic development environment to be sufficient to produce a robust, feature rich application. With this in mind, every vendor uses a custom toolset tailored to the unique needs of business management systems. This vendor-supplied toolset forms the second level. Finally, at the top level, the vendors use their toolset to develop their business logic.

Making the “wrong” comparisons

During sales situations, other vendors may try to coerce customers into making the wrong comparisons. They will incorrectly try to compare the Great Plains toolset (Dexterity) to the other vendor’s development environment (Visual Basic). Typically this comes across as a statement like: “Vendor X uses Microsoft Visual Basic, while Great Plains uses a proprietary, non-standard tool named Dexterity.” The diagram below exposes the flaw in this logic.

When comparing business management systems, we encourage you to compare the two
vendors’ development environments, the vendor’s custom toolsets, and the vendor’s
business logic (functionality).

One important difference between Great Plains and many other vendors is our use of C++ rather than Visual Basic as our base development environment. We believe our use of C++ is a strategic advantage that delivers significant customer benefits.

C++ vs. Visual Basic: Standards Support

To understand standards, we need to look at three commonly used terms:

Proprietary – “Exclusively Owned”

Webster’s defines “Proprietary” as “Exclusively Owned.”

Industry Standard – “Exclusively Owned, but very popular”

While this is my own definition, I think you’ll agree it’s accurate. For example, Crystal Reports is considered by most to be an “Industry Standard” product. Of course, Seagate Software exclusively owns Crystal. In the end, the only difference between an “Industry Standard” product and a “Proprietary” product is popularity.

Standards-Based – “Open, Multi-Vendor product”

While most people use the term “Industry Standard” on a daily basis, many don’t fully understand the far more powerful concepts behind a “Standards-Based” product. No one company controls a standards-based product. Instead, a national (ANSI) or international (ISO) standards group defines the core product functionality.

Now let’s look at C++ and Visual Basic in the area of standards support and see how this might impact “Built to Last.” C++ is a true standards-based product, with both ANSI and ISO working together on the standard. The ANSI group working on the C++ standard is designated “ANSI X3J16,” and the ISO group is “ISO WG21.” If you’d like more information, the entire C++ standards document is online at http://www.cygnus.com/misc/wp/ [Ed: broken link].

Because C++ is standards-based, there are two important ramifications for “Built to Last”:

1. No single company can arbitrarily remove or change core C++ functionality

Today, we use Microsoft Visual C++ as our C++ development tool. Because C++ is standards-based, we can rest assured Microsoft will not remove or change C++ functionality we are relying on today.

2. There are multiple vendors that supply C++-based development tools
Even if something catastrophic happened (perhaps there was a terrible bug in Microsoft C++ that rendered the product useless), our investment in standard C++ would be preserved. There are many other vendors that supply C++ tools for the Windows platform.

Now let’s look at Visual Basic. Visual Basic is only available from a single vendor (Microsoft) and it is definitely not a standards-based product. It should be clear the potential negative impacts this could have on “Built to Last.” This is far more than theory. In fact, other vendors who use Visual Basic have been significantly impacted several times. For example, one vendor wrote its entire product using Visual Basic 3.0 VBX controls. (VBX’s were Microsoft’s preferred method of creating controls on a Visual Basic window). This vendor created every control on hundreds of windows as VBX’s. When Visual Basic 4.0 shipped, Microsoft decided to simply remove support for VBX’s, and declare a new preferred method of creating controls: OCX’s. This forced the vendor to start from scratch and rewrite its entire user interface to support OCX’s. The result: untold hours spent rewriting interface code instead of adding value to their customers’ solutions.

C++ vs. Visual Basic: Technology Support

Getting the latest and best technologies to our customers first is critically important to Great Plains, and our architecture and design choices allow us to do this very effectively.

You may have heard other vendors claim that, since their product is “created” in Visual Basic, which is a Microsoft product, they therefore have an advantage in getting other Microsoft technologies to you first.

We’ve already demonstrated this argument doesn’t compare apples to apples, instead comparing one vendor’s custom toolset to another vendor’s development language. When we compare development languages, Microsoft Visual C++ to Visual Basic, we see both vendors are using Microsoft languages, and it becomes clear Visual Basic does not get the latest technologies first. In fact, there is typically a lag of several years before Visual Basic gets technologies. Consider the following diagram:

First, consider the fundamental technology of COM (the Microsoft Component Object Model), formerly called OLE in its early releases. COM is the “glue” that is the basis for all interapplication communication on the Windows platform. When first released as part of Windows 3.1 back in 1992, the only method of implementing this technology was via C/C++. Visual Basic did not gain this important technology until Visual Basic 3 shipped in early 1994, a two-year gap.

Next, consider 32-bit technology. When the first Microsoft 32-bit capable operating system, Windows NT, shipped in 1993, the only way to build a 32-bit application was using the C/C++ Software Development Kit from Microsoft. Visual Basic was not capable of producing a 32-bit application until Visual Basic 4 shipped in late 1995. Again, a two-year gap between C++ and Visual Basic.

Finally, consider Visual Basic for Applications (VBA). The first products using Microsoft VBA shipped in late 1996 using C++. You won’t see any Visual Basic bar on the chart because VBA, as shipped by Microsoft, is a technology that only C++ applications can integrate. One would expect, based on past trends, Microsoft will eventually create the ability for Visual Basic-based applications to directly integrate VBA. Meanwhile, C++ based applications like Dynamics have been giving customers the benefit of this new technology for over a year.

C++ vs. Visual Basic: Microsoft’s Actions Speak Louder than Words

Microsoft produces both Visual Basic and Visual C++. Because they produce both products you will rarely see statements from Microsoft positioning one product as “better” than the other product. However, to judge the suitability of using C++ or Visual Basic for producing commercial-grade, high-performing, scalable applications, one need only look at Microsoft’s actions to gain some insight.

The diagram below shows the major development tools Microsoft produces (C++, Visual Basic, J++, FoxPro, Access, etc…). Next we show the major products Microsoft sells, stacked on top of the development tool they use to build that product. The diagram shows C++ is clearly Microsoft’s “tool of choice” for building all of their commercial grade applications. In addition to the applications shown (like Office or SQL Server), many other Microsoft applications are also written in C++ (Exchange, SM, Internet Information Server, Site Server, etc.).

The large “NOT” sign indicates Microsoft does not use Visual Basic (or any of the other tools) as the base development environment for any of its major products.

As our last item on our comparison of the suitability of C++ vs Visual Basic for building large, mission critical, high-performing applications like business management systems, I’d like to quote “the man in the know,” Bill Gates, Chairman and CEO of Microsoft. At a recent public Q&A session Gates was asked the following question:

Q: “If someone wanted to be set for tomorrow, what tools should they be using from Microsoft’s perspective?”

Bill Gates: “For simple applications Visual Basic does very well. Even for some of the larger corporate applications, we’ve been able to scale that up quite a bit.

People who do heavy-duty development: they are using C today, and they are going to be using C five years from now… It just lets you get at a level in terms of managing memory, managing type systems, that other languages don’t let you get at.“

---

For information on C++ standards please visit http://www.open-std.org/jtc1/sc22/wg21/

In the next article Tim reviews “Built to Grow“.

Until next post!

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

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/

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/07/2010	Conclusion
04/09/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/

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

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/

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

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/

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/