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

November 17, 2011

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/

Advertisements

Adobe PDF Converter error when sending report to PDF in Microsoft Dynamics GP

December 9, 2010

Just recently, I was working on a few Report Writer reports for a client and assisting with installing the latest Adobe Acrobat Standard version for them. After Adobe was installed, we decided to run a few tests to attempt to send some of the modified reports output via email using the Send To > Mail Recipient PDF option on the Report Output window.

Send To > Mail Recipient PDF

Upon choosing the Mail Recipient PDF option, we received the following error:


Adobe PDF Converter error



The error seems to come from the Adobe PDF Converter application which suggested that our PDF conversion process must rely on the system fonts and use document fonts. In addition, the message provided the path to address the issue as well, so we followed.
Initially, you must go to the Devices and Printers panel in Microsoft Windows, then right click on the Adobe PDF Converter printer and choose Printer Properties.
Devices and Printers panel
Once the Adobe PDF Converter Properties window opens, click on the Preferences button
Adobe PDF Converter Properties window

The Preferences button will now open the Adobe PDF Converter Printing Preferences window, where the option referring to the specific error comes to surface:

Adobe PDF Converter Printing Preferences window

Once the checkbox was unmarked, we were able to re-test our reports and everything worked just as intended.

If you ever run across this error, just know that the fix is very simple.

Until next post!

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


Enabling a Report Writer document as a Word Template

December 6, 2010

Ok, this is directly or indirectly a Report Writer subject, but nonetheless a topic related to Report Writer. In this example, I take the General Posting Journal transaction document and enable it under Word Templates. However, this example will not develop the Word Template itself, but rather show how easy it is to make the journal document template enabled.

The steps are very simple and in fact, with a little bit of creativity, a developer could potentially write code that quickly enables critical reports.

To enable an existing Microsoft Dynamics GP report:

1. Register a trigger against the IsTemplateEnabledReport() function of the syReportLookup form. Template enabled reports can be selected in the Reports lookup window.

Startup

{ Created by Mariano Gomez, MVP
This code is licensed under the Creative Commons
Attribution-NonCommercial-ShareAlike 2.5 Generic license.
}
local integer l_result;

pragma (disable warning LiteralStringUsed);

l_result = Trigger_RegisterFunction(function IsTemplateEnabledReport of form syReportLookup, TRIGGER_AFTER_ORIGINAL, function glPostingJournalReport);
if l_result <> SY_NOERR then
warning "Trigger registration for General Posting Journal report failed.";
end if;

pragma (enable warning LiteralStringUsed);

Note: You will need to save the Startup script first (CTRL+S), and compile the dictionary when the trigger processing function is implemented.

2. Now that we have our Startup script and the trigger registered, we can implement the trigger processing function. In this case, I have labeled this function glPostingJournalReport().

glPostingJournalReport()

{ Created by Mariano Gomez, MVP
This code is licensed under the Creative Commons
Attribution-NonCommercial-ShareAlike 2.5 Generic license.
}
function returns boolean result;

in 'Product ID' nProdID;
in Resid nResID;

if nProdID = DYNAMICS then

{It's our report. Indicate that it is template enabled.}
case nResID
in [resourceid(report 'General Posting Journal')]
result = true;
end case;
end if;

Note: In the above code I am using the dictionary constant DYNAMICS for the product ID as our report belongs to the core dictionary. Also, rather than hardcoding the resource Id for the report, I am using SanScript’s resourceid() function to obtain the resource Id for the report.

3. Open Dexterity Utilities to extract and autochunk your dictionary into a final product. The following are the settings I used for this particular project:



Auto-Chunk and Product Information windows

4. Drop your chunk file in the Dynamics GP folder and make sure that you can see your trigger in action in the Reports lookup window under Report Template Maintenance.



Reports Lookup window


Now that we have won half the battle, I will show in my follow up post, how to actually implement the template and make it all work together.

Downloads:

Extracted dictionary – Click here
Chunk file – Click here

Until next post!

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


Report Writer Week!

December 6, 2010
In this corner: David Musgrave
In this corner: Mark Polino
In case you have missed the heated debates – all within cordiality, though there was even a call for insanity – between David Musgrave and Mark Polino on Report Writer, I now join in to continue fueling the heat by declaring this the official Report Writer week!
To make this an even more attractive proposition for you the reader, The Dynamics GP Blogster is siding  (more like ganging up against Mark 🙂 ) with Developing for Dynamics GP to deliver some really cool Report Writer articles and to show some advanced techniques for developing reports… yes, with Report Writer.

Until next post!

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


New Article on MSDynamicsWorld: "When It Comes to Customizations for Microsoft Dynamics GP, Which Tool Should You Rely On?"

July 16, 2010


“The term “customization” can mean different things to different people…”

My new article is out over at MSDynamicsWorld. This time, I go back to basics defining what is a customization and what tools are available to customize the Microsoft Dynamics GP user interface. This article is a good start if you are still trying to figure out your options for developing add-on solutions to Microsoft Dynamics GP. To read the full article, click here.

Until next post!

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


RW – Creating Branching Logic Fields in Report Writer

March 19, 2010

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


Parsing Long String fields in Extender for using with Report Writer

January 14, 2010

A few days aback I came across a Partner Forum question where the partner was attempting to add an Extender field to a Report Writer report, not without his share set of challenges.

In their infinite wisdom, the folks at eOne added a trigger to the rw_TableHeaderString Report Writer function which allows them to expose data to Report Writer without having to create alternate versions of a report in their application. In turn, with a few steps outlined in the Extender manual, users can invoke the rw_TableHeaderString as a user-defined function in a string calculated field to retrieve the piece of data needed from an Extender table by passing in the Window ID, the key fields, and the position of the field to retrieve on the Extender window. This is an example from such call:


Calculated Field: EXTENDER_KEY
Expression Type: Calculated
Result Type: String
Expression: STRIP( SOP_HDR_WORK.SOP Number )

Calculated Field: (C) AdditionalShippingInfo
Expression Type: Calculated
Result Type: String
Expression: FUNCTION_SCRIPT( rw_TableHeaderString 3107 “EXTRA_SOP_INFO” EXTENDER_KEY 0 1 )

This is all good! But here comes the issue… Extender Long String fields are 255 characters long and Report Writer string calculated fields support up to 80 characters. The partner tried to use the rw_ParseString Report Writer function to parse the Extender string in various lines as follows:


Calculated Field: (C) AdditionalShippingInfo_Line1
Expression Type: Calculated
Result Type: String
Expression: FUNCTION_SCRIPT( rw_ParseString FUNCTION_SCRIPT( rw_TableHeaderString 3107 “EXTRA_SOP_INFO” EXTENDER_KEY 0 1 ) 50 1)

Calculated Field: (C) AdditionalShippingInfo_Line2
Expression Type: Calculated
Result Type: String
Expression: FUNCTION_SCRIPT( rw_ParseString FUNCTION_SCRIPT( rw_TableHeaderString 3107 “EXTRA_SOP_INFO” EXTENDER_KEY 0 1 ) 50 2)

Of course, when the report was executed it threw an “Error in Equation” error as Report Writer does not support nesting of user-defined function scripts.

At this point, the only option available in order to be able to retrieve a long string and print it on the report is VBA, ADO, and a SQL Server view. The following is the process with references to articles that will help you with each step:

1. Create an Extender view of your data. You may start by reviewing Creating SQL Views of Extender Data over at Developing for Dynamics GP to get an understanding of this process. David Musgrave also outlines a sample view to get you started.

2. Create string calculated fields on your report that will be used to parse the Extender Long String field.

3. Add your report to VBA and add the string calculated fields created in step 2 to the VBA project. Also, add any key fields on the report needed to retrieve the data, i.e., SOP Number.

4. Use ADO to query the view for the information stored and store the data in the calculated fields. You may want to review Using ADO with VBA with Report Writer over at Developing for Dynamics GP for samples on the technique.

While the workaround might seem a bit lengthy, the results will speak for themselves, so don’t give up on Report Writer just yet :).

Until next post!

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