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 – 3 of 4

Codename GP “12” Preliminary Features – Part 3 

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

---

If you were taken by the Simplicity and Productivity features, then you will be more impressed with the this new list of features aimed at enhancing the Microsoft Dynamics GP product depth.

Product Depth features

Receivables Management Enhancements

As of the current release, it has always been necessary to enter and apply multicurrency cash receipts as a two-step process. MC Apply in Cash Receipts will now allow you to take a cash receipt entered in originating currency and apply it against an invoice all in the same transaction entry process.

Payables Management

Void of Check Return Applied Credits (return/credit memo) to reusable state – For example, if you have an invoice ($100) with a payment of $50 and a credit memo for $50, both applied to the invoice, you will be able to void the check and have the credit memo become available to either use against the same invoice or apply it to another document – the credit memo returns to an unapplied state. If the original payment was made by credit card, the invoice created for the credit card vendor will also be voided automatically.
Fixed Assets Enhancements

The Fixed Assets module has seen considerable improvements. New also is the Fixed Assets Historical Depreciation Reports. If you have tried to run a historical report, it was not possible and the system would retrieve all the previous depreciation information. Now you can select a specific depreciation date for your report.

System Enhancements

Document Attach. Are you tired of trying to fight your way with the Dexterity OLE Notes Container? First I should clarify, the OLE Notes Container will remain an integral part of Microsoft Dynamics GP. After all, there are a number of you using out there. However, now you will have a more powerful tool in Document Attach.

Document Attach

General Ledger Enhancements

GL Year End Close Options. This feature will provide an option to clear out balance for unit accounts.  Currently, unit account balances automatically carry over from the previous year. The year-end process now features a progress bar that will indicate how far you are into the process when executing it. GP “12” will also provide an option to NOT delete budget account with balances.

I hope you are enjoying some of these preliminary features. My next article will discuss some of the product innovations and what you can expect from a technology perspective..

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/

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

Codename GP “12” Preliminary Features – Part 1 

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

---

I am only repeating what I have heard so please don’t shoot the messenger. With GP “12” to be released “sometimes next year” – and yes, December 31, 2012 is still within that time frame – there may still be features on the following list that may not make the cut. However, it was fairly clear that the boys and girls on the Microsoft Dynamics GP development team in Fargo are working their rears off to get the feature list to a state where they feel pretty comfortable, meeting the demands on the shopping list.

Straight out of GPUG Summit’s closing session, comes some of the top features being worked on, based on the traditional 4 pillar goals:

4 Core Design Pillars

Each pillar allows the engineering team to showcase a list of features that will support the objectives behind pillar.

Simplicity

The PM Reprint Check Remittance, for instance, will allow users to re-print the check remittance without having to generate the check.

Improvements have also been considered for the FA Calendar Setup feature. In this case, the Fixed Assets calendar does not have to match the fiscal calendar. You can now have multiple calendars, for example, having an asset depreciate on a fiscal year for tax purposes, if tax year and fiscal year are different, and depreciate calendar year for financial reporting purposes.
  
The Journal Entry History Inquiry will see enhancements too. In today’s world, the existing window only looks at the open tables. The plan for GP “12” is to have it look at both open and/or history.

In the reporting area, you will be delighted to know that you will now be able to choose a printer at print time. This feature was only 20 years in the making, but it’s finally here! Hey, I remember like if it was yesterday, when Windows True Type fonts became a standard part of Report Writer reports. Before that, we only had 4 fonts to play with. Challenge: name the 4 fonts available prior to the introduction of True Type fonts.

SSRS Simplicity

In addition to the printer at print time, one of the most awaited features is the ability to print SSRS reports from right within Microsoft Dynamics GP, this is, you will no longer need to wait for the Internet Explorer browser to load Report Server to display the report and will rather see the report from within GP as if you were looking at a Report Writer report in the report layout window… ah, and before I forget, Report Writer will eventually be phased out as the predominant options to render reports.

I don’t know how this plays with all that Word Template functionality released fairly recently, but I am sure a lot of you will jump on one feet in happiness knowing that you no longer will need to suffer through the tortuous process of customizing a report. My instinct tells me, that Report Writer will mainly subsists as a data delivery mechanism for XML files needed for your beloved Word Templates. If history and memory serve me well, Microsoft rarely gets rid of a working function within its products, except it becomes as annoying as the Office Paperclip Assistant. Now that I come to think, Report Writer is got to be up there for a lot of you.

I will continue tomorrow with the Productivity pillar.
Until next post!

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

Microsoft Dynamics GP Roadmap Update – Welcome codename GP "15"

Exciting times to be in the Microsoft Dynamics GP world! Web Client on the horizon, cloud computing in the not so distant future, tons of enhancements in codename GP “12”. Now that I come to think about it, kind of make GP 2010 sound a bit obsolete, but wait? GP 2010 just got a refresh a few months ago. Oh, well!

If you keep up with my blog, you probably have seen my previous articles on the GP roadmap. For your benefit however, here are the links:

The Evolution of the Microsoft Dynamics GP Roadmap
Microsoft Dynamics GP Roadmap Update
Microsoft Dynamics GP roadmap

Now, I unveil for you the new roadmap which includes codename GP “15”

Roadmap as of November 2011 (GPUG Summit)

This roadmap update was unveiled at the GPUG Summit 2011 in Las Vegas, Nevada. Note that codename GP “15” includes a Rapid Time-to-Value focus for the middle market, which probably means you will see some improvements in the implementation and deployment cycles of the product, a carry over topic from codename GP “14”. One has to imagine that given the changes in the core product architecture, deployment would become a focus going into the future.

As usual, if anything new comes up I will let you know about it – as long as I am not bound by my NDA.

Until next post!

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

Jumping on the Windows 8 Metro bandwagon

In my most recent In My Humble Opinion article I weigh in on the subject of Windows 8 Metro and Microsoft Dynamics GP “12” web client, and Microsoft’s decision to go it the Silverlight route. Read why I think Silverlight is still the best choice as a development platform and how Windows 8 can still drive business applications requiring rich controls on the front-end.

You can read the article at – Jumping on the Windows 8 bandwagon on the Community site.

For more information on Windows 8, including a link to download the Developer’s edition, click below:

Read more at the Microsoft News Center

Download the Windows Developer Preview

Until next post!

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

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/