Codename GP "12" Preliminary Features Series – Wrap Up

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/

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

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/

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

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/

Microsoft Dynamics GP "12" Multi-tenant Services Architecture

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/

Microsoft Dynamics GP "12" Architecture: Correction!

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/

Microsoft Dynamics GP "12" Named System Database Architecture

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.

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

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/

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

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/

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

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/

Microsoft Dynamics GP "12" Web Client Architecture Series

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 Date	Featured Article
05/09/2011	Microsoft Dynamics GP “12” Web Client Architecture – Part 1
05/11/2011	Microsoft Dynamics GP “12” Web Client Architecture – Part 2
05/16/2011	Microsoft Dynamics GP “12” Web Client Architecture – Part 3
05/23/2011	Microsoft 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.