How to Display Parent Company Information on SOP documents

A few days aback I encountered a really interesting discussion on the Microsoft Dynamics GP Community forum where the user needed to get the parent customer information on the SOP Blank Invoice Form. I asked myself, "Well, how difficult can that be?"

The first thought around these requests is, you create a table relationship between the Sales Transaction Work (SOP_HDR_WORK) table and the RM Customer Master (RM_Customer_MSTR) table by Customer Number and you get the parent customer ID. In that train of thought you immediately realize that there's no way to alias the RM Customer Master table back into the table relationship to retrieve the parent customer ID information. [NOTE TO SELF: this would be a cool Report Writer feature, but I digress.]

Of course, a second alternative is to use VBA, but many customers and partners are wary of implementing a VBA solution, especially when they are considering upgrading to Microsoft Dynamics GP 2013 and taking advantage of the web client. VBA customizations simply do not work with the web client.

As I thought through an alternative, I quickly realized this would be a good fit for the Support Debugging Tool and it's awesome Runtime Execute feature. As it turns out, the Support Debugging Tool is capable of executing Dexterity sanScript code within the context of any dictionary, but not only that; it provides some really cool templates that save time and minimizes the amount of code an entry level developer needs to create to accomplish a solution. In turn, there are a number of Report Writer API scripts built into the Dynamics application dictionary (DYNAMICS.DIC) to allow third party developers to expose data from their tables onto an existing Microsoft Dynamics GP report without having to write a complex interface to do so.

The Solution

1. The first task at hand is to open the Runtime Execute window in the Support Debugging Tool. Once the window is open, click on the Helper button to open the Insert Helper Function window. From the drop-down list, select template for rw_TableHeaderString.

Insert Helper Function window

Below is the signature for the function as we will use it.

The rw_TableHeaderString function

function returns string sData;

in integer dict_id;  {Support Debugging Tool Dictionary ID}
in string report_name;  {Support Debugging Tool Script ID to call}
in string sNumber;  {Parent Customer ID field we will retrieve}
in integer sType;  {Not used, we will default to 0}
in integer iControl;  {which piece of data to return} 

We will use this function to return a string value for the selected Parent Customer ID information field to a Report Writer calculated field.

By clicking OK, the Support Debugging Tool inserts the code to get us started in the right direction.

Helper Code

Very cool! All that's left now is to add the extra bits of code to retrieve the parent customer information from the RM Customer Master. In addition, we need to make sure that this code executes in the context of the Microsoft Dynamics GP product.

Additional Code

The template function even indicates where our code should be inserted and as you can see this is easy stuff for any entry level Dex developer. All we did here was use the MBS_Number local field as the parameter value that will contain our parent customer ID (to be passed from Report Writer) to get the piece of data we are interested in based on the value that we will supply to the MBS_Control local field (again, from Report Writer). The returned table value will then be stored in the MBS_TableHeaderString local field.

The Support Debugging Tool then goes to action and call its MBS_Param_Set API function to talk back to the Report Writer API script and deliver the values retrieved to it. Isn't this awesome!

2. The second part of our solution consists of 3 parts really: a) we need to create a table relationship between the Sales Transaction Work table and the RM Customer Master table as this relationship does not exist out of the box, b) We then need to create calculated fields for the pieces of Parent Customer data we would like to retrieve, and c) We need to complete the layout and grant security to the modified report.

I will assume for this article that you are familiar with the processes of creating new table relationships in Report Writer and laying out the new calculated fields and granting security to the modified report. You can always browse the Report Writer manual accompanying your Microsoft Dynamics GP application for information of these processes, so my attention will focus solely on the calculated field.

In this example, I want to retrieve the parent customer name. For this we will create a new calculated field as follows:

a) Create a new calculated field, in this case I will call it (A) Parent Name. The result type of the calculation will be a String and the expression type is Calculated.

b) Since we are using the rw_TableHeaderString user-defined function, we will choose this accordingly:

rw_TableHeaderString

c) Now we have to setup the parameters as indicated by the function signature above. The first parameter we will add is the Support Debugging Tool's dictionary ID, 5261. We will add this as an integer constant.

Dictionary constant 5261 to call the script we wrote

d) Now we have to call the Runtime Execute script we created, GETPARENTINFO. We will add this as a string constant.

GETPARENTINFO

e) We now need to pass the parent customer number parameter, our default (not used) parameter, and the value number for the field that will be retrieved for the parent customer data, according to how we coded our script above. This is shown below.

Last 3 parameters.

The RM_Customer_MSTR.Corporate Customer Number field is retrieved from the RM Customer Master table which we created via a new table relationship and subsequently adding that table relationship to our report.

The following shows a muck-up of the report layout with the parent customer name calculated field created:

Report Layout

The report should display something like this when run in Microsoft Dynamics GP:

Invoice Layout

Final Notes

The above script could be extended to retrieve other pieces of data for our parent customer, like contact, address, city, state, zip, phone numbers, etc. In this case you will need to add more entries to the case...end case statement above and retrieve the correct table column. You can find more information on the table columns for the RM Customer Master in the Microsoft Dynamics GP software development kit (SDK).

This solution is absolutely compatible with Word Templates and the Web Client. In the case of Word Templates, you will need to export a new report definition file (XML) and import into your template fields. In the case of the Web Client, all the components above are within the confines of a Dexterity application and the Support Debugging Tool happens to be compatible with the Web Client, just as much as Report Writer is. Your modified report should render absolutely fine on the Silverlight canvas control, if printing the standard report.

For all workstations to take advantage of the Runtime Execute script, the Support Debugging Tool must be deployed with the recommended configuration - all workstations pointing to a centralized configuration file, debugger.xml.

---

The Support Debugging Tool never ceases to amaze me. You can find similar article to this one and more information here:

The Dynamics GP Blogster - Adding Customer Item User Defined Field to SOP Invoice

Developing for Dynamics GP - The Support Debugging Tool Portal

Until next post!

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

Read More

Adding more comment lines to POP Purchase Orders

Just recently, I was asked by a customer to address an issue with their line item comments truncating at 4 lines. In essence, the customer wanted the ability to print more than 4 lines of comments at the line item level on their purchase orders.

My customer happens to be in the Nuclear Waste Management industry, and as it turns out, they have strict requirements to provide contract information, start/end dates, and a number of regulatory and compliance information on purchase orders. Some of this information is very critical to the transportation of certain products on United States highways. So as you can imagine, the request for additional comment lines was critical.

The following shows an example of what the customer was facing:

Purchasing Comment Entry window and POP Purchase Order Blank form

As you can see, the comments are printing only 4 lines and truncating the rest of the text.

Before going into the details, they are a few articles that guided me through the solution:

How to Display More Than Four Line Item Comments in the "SOP Blank Invoice Form" Report in Sales Order Processing in Microsoft Dynamics GP

Adding more comments to SOP Documents (Developing for Dynamics GP)

Of course, these articles refer to SOP, but the underlying techniques used in them will allow us to make the necessary changes to the report. This blog post should be used in conjunction with the How To article above to provide some additional steps to get the best result for making the changes to the POP Purchase Order report.

Background

Comments for Purchase Order Processing (POP) transactions are entered using a text field which allows for a maximum of 500 characters, as shown above. When the comments are saved, the text field is divided into 4 string fields of 50 characters each, which is printed on the report. The code that parses the text field into the 4 string fields is smart enough to avoid splitting a word oddly.  The code will fit as many words as it can up to the last space before the 50 character mark or up to a carriage return (new line). When the POP documents are printed, it is these 4 comment string fields which are printed on the report. This means that if you use carriage returns or type a comment longer than 180-200 characters, you are unlikely to see all of your comment text shown on the report.

If you look at a POP document report, such as the POP Purchase Order Blank Form, you will see that the 4 comment lines are printed using 4 additional footer sections.

POP Purchase Order Blank Form Report Writer Layout showing 4 footers (F3 - F6)

Looking at each of these additional sections (Tools > Section Options), you will see that each one is configured to be Suppressed when the appropriate 'sSuppressCommentX' calculated field is empty. The 'sSuppressCommentX' calculated field is defined to look at the comment string array report field and return an empty string or the actual comment to be printed on that footer. The reason for all this complexity is so that the space for the comment line strings is only taken up when there is actually a comment line to display. If this technique with additional footers with conditional suppression was not used, there would be 4 lines between every POP line item whether it was used or not - not an efficient use of already cramped space.

Solution

The solution is to use the RW_POPLINECommentText user-defined Report Writer function in the system series in a set of calculated fields.  The same recommendations apply as with the SOP article above, this is, making each line the maximum 80 characters supported by Report Writer strings and creating 8 lines. This gives the potential for 640 characters and so should easily be able to display the 500 characters of comment text (even without breaking words in half or additional carriage returns).

Why 8 lines? This is so we can place two lines on each of the 4 additional footer sections. If we update the suppression logic correctly, it will mean there will only be the possibility of one blank line between SOP line items. With only 4 section breaks, we can only print 0, 2, 4, 6 or 8 lines at a time, so if there are actually an odd number of lines to be printed, there will be one blank line printed. If there are an even number of lines, then there will be no blank line.

For an explanation on why not using additional footers instead, see Adding more comments to SOP Documents over at Developing for Dynamics GP.

The parameters for the RW_POPLINECommentText function are as follows:

RW_POPLINECommentText()

function returns string OUT_string;
in integer IN_Type;   { POP Type of Document }
in string IN_Number;   { POP Number of Document }
in long IN_Ord;    { Ord Number of Line }
in integer IN_characters;  { Number of Characters per Line }
in integer IN_line;   { Line Number to Return }

Implementation

The steps below assume some knowledge of Report Writer. If you need detailed step by step instructions please look at the How to document.

Line Comments

1. Create 8 calculated fields of result type string for the 8 Line level comment lines:

(C) Line 1 Comments = FUNCTION_SCRIPT( RW_POPLINECommentText POP_PO.PO Type POP_PO.PO Number popPOLineRollupTemp.Ord 80 1 )

(C) Line 2 Comments = FUNCTION_SCRIPT( RW_POPLINECommentText POP_PO.PO Type POP_PO.PO Number  popPOLineRollupTemp.Ord 80 2 )

(C) Line 3 Comments = FUNCTION_SCRIPT( RW_POPLINECommentText POP_PO.PO Type POP_PO.PO Number  popPOLineRollupTemp.Ord 80 3 )

(C) Line 4 Comments = FUNCTION_SCRIPT( RW_POPLINECommentText POP_PO.PO Type POP_PO.PO Number  popPOLineRollupTemp.Ord 80 4 )

(C) Line 5 Comments = FUNCTION_SCRIPT( RW_POPLINECommentText POP_PO.PO Type POP_PO.PO Number  popPOLineRollupTemp.Ord 80 5 )

(C) Line 6 Comments = FUNCTION_SCRIPT( RW_POPLINECommentText POP_PO.PO Type POP_PO.PO Number  popPOLineRollupTemp.Ord 80 6 )

(C) Line 7 Comments = FUNCTION_SCRIPT( RW_POPLINECommentText POP_PO.PO Type POP_PO.PO Number  popPOLineRollupTemp.Ord 80 7 )

(C) Line 8 Comments = FUNCTION_SCRIPT( RW_POPLINECommentText POP_PO.PO Type POP_PO.PO Number  popPOLineRollupTemp.Ord 80 8 )

Note: The only difference for each calculated field is the line number in the field name and the line number constant as the last parameter.

2. Expand each of the comment additional footers to 2 lines height.

3. Move the 4 existing Comment fields to the right of the report.

4. Double Click on each of the 4 old Comment array fields and set the Visibility to Invisible.

Comment Footers and Invisible Fields

5. From Calculated Fields drag out the 8 new calculated fields placing two fields in each section. Drag out the field width as desired (at least 370).

Calculated fields on footer sections

6. The 4 sSuppressCommentX calculated fields will need to be changed to conditional fields and the return type changed to Integer, as shown:

Calculated Field definition

sSuppressComment1 = F6_LAST (C) Line 1 Comments = "" AND  F6_LAST (C) Line 2 Comments  = ""

sSuppressComment2 = F5_LAST (C) Line 3 Comments = "" AND  F5_LAST (C) Line 4 Comments = ""

sSuppressComment3 = F4_LAST (C) Line 5 Comments = "" AND  F4_LAST (C) Line 6 Comments = ""

sSuppressComment4 = F3_LAST (C) Line 7 Comments = "" AND  F3_LAST (C) Line 8 Comments = ""

After all these changes, it's time to save the report and test:

Purchase Order Blank Form

Now we can see the full line item comment displays nicely on the report.

Downloads

You can download the package file for this customization here.



POPBlankFormExtendedNotes.zip

Until next post!

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

Read More

Adding Customer Item User Defined fields to SOP Invoice

Just recently I ran across a request to add the Customer Item user defined fields to the Sales Blank Invoice Form report in Report Writer. As usual with these type of requests, chances are it's been done before and/or it's probably documented in some KB article.

As it turned out, KB article 918943 outlines the steps required to add the Customer Item Number to the Sales Blank Invoice Form report:

How to add the "Customer Item Number" field to a quote, order, or invoice form in Sales Order Processing in Microsoft Dynamics GP

The KB article however, makes use of the Report Writer function rw_SOP_GetCustomerItemNumber to get around the issue. There's also an additional Report Writer function, rw_SOP_GetCustomerItemDescription which allows you to retrieve the description for the customer item. Now, that's all cool, but what about the user-defined fields?

Customer Item Maintenance

The screenshot above highlights the fields in question. As it turned out, there are no Report Writer functions to retrieve those.

In looking at possible ways to add these fields you could try 3 different things:

1. Use Modifier with VBA to retrieve the user-defined fields. While this is a viable solution, the partner was adamant about not using VBA because of lack of supportability on the Microsoft Dynamics GP 2013 Web Client.

2. Table relationships in Report Writer. After looking at the table keys on SOP_LINE_WORK (SOP10200) and sopCustomerItemXref (SOP60300), I concluded that table relationships would not work either. The problem here is that the SOP_LINE_WORK table does not contain the Customer Number field, required to be able to establish a relationship to the sopCustomerItemXref. After all, if the field existed, there would be no need for the Report Writer functions mentioned above.

3. Support  Debugging Tool. The SDT has the ability to encapsulate Dexterity code with it's Runtime Execute feature. That code can be saved to a Script ID. Furthermore, the Support Debugging Tool leverages the 6 generic Report Writer functions available in the Microsoft Dynamics GP dictionary. These functions were created to allow third party developers a way around an Alternate Report, with the ability to retrieve data from their tables.

For more information on the generic Report Writer functions, take a look at KB article 888884:

Useful functions for developers to use instead of creating alternate reports in Microsoft Dynamics GP

Given all the options and drawbacks, it was decided that Support Debugging Tool would be able to accomplish the job. Since it's a Dex application, it certainly would move forward to Microsoft Dynamics GP 2013 and Web Client, and in addition, would be able to work around the table relationships issue.

---

One thing I like about the Support Debugging Tool's Runtime Execute is the ability to use the Helper functions. In particular, the helper function needed is one that allows us to leverage a generic Report Writer function, the rw_TableLineString, while line items are being printed on the report - when a line item is displayed, we must display the corresponding Customer Item user defined field.

Insert Helper Function window

Since there's a template for the above function, all we need to do is click on the Ok button. As if the Support Debugging Tool wasn't already helpful, it now autogenerates some of the code needed to work with the rw_TableLineString:

Runtime Execute window with auto-generated Dexterity code

All that's left now is to add a script ID and enter the bit of code needed to retrieve the user-defined fields:

Runtime Execute script

The full version of the script can be found below:
Script ID: CUSTITMUDF

local string MBS_TableLineString;
local string MBS_Number;
local integer MBS_Type;
local currency MBS_SequenceOne;
local currency MBS_SequenceTwo;
local integer MBS_Control;
local string MBS_String;

{Declarations}
local string ItemNumber;
local string CustomerNumber;

call with name "MBS_Param_Get" in dictionary 5261, "Number", MBS_Number;
call with name "MBS_Param_Get" in dictionary 5261, "Type", MBS_String;
MBS_Type = integer(value(MBS_String));
call with name "MBS_Param_Get" in dictionary 5261, "SequenceOne", MBS_String;
MBS_SequenceOne = currency(value(MBS_String));
call with name "MBS_Param_Get" in dictionary 5261, "SequenceTwo", MBS_String;
MBS_SequenceTwo = currency(value(MBS_String));
call with name "MBS_Param_Get" in dictionary 5261, "Control", MBS_String;
MBS_Control = integer(value(MBS_String));
MBS_TableLineString = "";

{ Add your code below here }

{ Retrieve the item number in question }
clear table SOP_LINE_WORK;
set 'SOP Number' of table SOP_LINE_WORK to MBS_Number;
set 'SOP Type' of table SOP_LINE_WORK to MBS_Type;
set 'Line Item Sequence' of table SOP_LINE_WORK to MBS_SequenceOne;
set 'Component Sequence' of table SOP_LINE_WORK to MBS_SequenceTwo;

get table SOP_LINE_WORK by number 1;
if err() = OKAY then
 set ItemNumber to 'Item Number' of table SOP_LINE_WORK;
end if;

{ Now, get the customer number }
clear table SOP_HDR_WORK;
set 'SOP Number' of table SOP_HDR_WORK to MBS_Number;
set 'SOP Type' of table SOP_HDR_WORK to MBS_Type;

get table SOP_HDR_WORK by number 1;
if err() = OKAY then
 set CustomerNumber to 'Customer Number' of table SOP_HDR_WORK;
end if;

{Since we have the customer number and item number, we should now be able to
 retrieve the customer item number
}

if not empty(ItemNumber) and not empty(CustomerNumber) then
 clear table sopCustomerItemXref;
 set 'Item Number' of table sopCustomerItemXref to ItemNumber;
 set 'Customer Number' of table sopCustomerItemXref to CustomerNumber;
 
 get table sopCustomerItemXref by number 1;
 if err() = OKAY then
  case MBS_Control 
   in [1] {UDF 1}
    MBS_TableLineString = 'User Defined 1' of table sopCustomerItemXref;
   in [2] {UDF 2}
    MBS_TableLineString = 'User Defined 2' of table sopCustomerItemXref;
   in [3] {UDF 3}
    MBS_TableLineString = 'User Defined 3' of table sopCustomerItemXref;
   in [4] {UDF 4}
    MBS_TableLineString = 'User Defined 4' of table sopCustomerItemXref;
   in [5] {UDF 5}
    MBS_TableLineString = 'User Defined 5' of table sopCustomerItemXref;
   in [6] {UDF Key 1}
    MBS_TableLineString = 'User Defined Key1' of table sopCustomerItemXref;
   in [7] {UDF Key 2}
    MBS_TableLineString = 'User Defined Key2' of table sopCustomerItemXref;
   in [8] {UDF Key 3}
    MBS_TableLineString = 'User Defined Key3' of table sopCustomerItemXref;
   in [9] {UDF Key 4}
    MBS_TableLineString = 'User Defined Key4' of table sopCustomerItemXref;
  end case;
 else
  MBS_TableLineString = "";
 end if;
end if;

{ Add your code above here }

call with name "MBS_Param_Set" in dictionary 5261, "TableLineString", MBS_TableLineString;

Cool balloons! One aspect of the programming was, how to leverage the same function (as opposed to creating multiple scripts that would perform the same operations) to pull in different UDFs? As it turns out, there's a parameter in the rw_TableLineString function, which allows you to specify a control value which determines the position of the piece of data to be returned. This control value is an integer type. Knowing this allowed me to send in a numeric value for the UDF I wanted to retrieve and define a case...end case statement evaluating the control parameter to return the proper UDF field.

---

Finally, the rest is just house keeping at the Report Writer level... First, we must create two currency calculated fields: one for the Line Item Sequence and another for the Component Sequence. As it turns out, our Report Writer custom function requires two currency parameters. Below is the rw_TableLineString function signature

rw_TableLineString()

in integer dict_id; {Dictionary ID}
in string script_id; {Script ID} in string sNumber; {control field 1}
in integer sType; {control field 2}
in currency cSequenceOne; {control field 3}
in currency cSequenceTwo; {control field 4} 
in integer iControl; {which piece of data to return}

Our calculated fields are shown below:

(C) Component Sequence calculated field

(C) Line Item Sequence calculated field

Finally, we need a calculated field to invoke our Report Writer function, which in turn will call our script ID created in Support Debugging Tool. In this specific case, we are going to retrieve the Customer Item user-defined field 1.

CustomerItemUDF1 Calculated Field

FUNCTION_SCRIPT( rw_TableLineString 5261 "CUSTITMUDF" SOP_LINE_WORK.SOP Number SOP_LINE_WORK.SOP Type (C) Line Sequence Number (C) Component Sequence 1)

We can now move our CustomerItemUDF1 calculated field onto the report layout:

After granting security to the modified report, we can print an invoice to verify the report works.

As you can see, once more we have leveraged the power of the Support Debugging Tool to deliver what would have otherwise seemed like a difficult or unattainable customization to a report. I hope this is yet another incentive to install the tools and begin taking advantage of its features.

Until next post!

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

Read More

Word Templates rendering report in Internet Explorer

I have been working on a Word Templates case for the past 2 weeks and just got to the bottom of the problem, hence I felt the need to pause and blog about it.

Background

A client of mine reported a couple weeks aback that they had created a template version of their purchase order and each time the purchasing staff attempted to print a purchase order, the output would automatically generate in Internet Explorer instead of Microsoft Word. As the title of this article suggests, the client is using Word Templates to generate a nice looking PO for their vendors.

HTML POP Purchase Order Blank Form

However, and to make matters more interesting, when they printed a standard sales invoice, SOP Blank Invoice Form, these would generate just fine in Microsoft Word.

Troubleshooting

In troubleshooting this process, we went through all the formal setup and steps to create a template in Microsoft Dynamics GP, with the added benefit that the client's purchase order form was not a modified report. I also outruled the Word Add-On for Microsoft Dynamics GP being an issue, since the sales invoices were being created just fine.

I made sure the client was not accidentally selecting HTML as the default output. As previously mentioned, when the purchase order was printed, it would automatically go to Internet Explorer. We also selected a File output and the Microsoft Word file would automatically get an html extension following the docx; for example, POP Purchase Order Blank Form.docx.html.

Printing Purchase Order Document

When printing the purchase order, one thing stood out in the printing process... the Report Type drop-down list would automatically default to Standard -- not to Template as would be expected -- and the client would have to manually select Template before clicking Ok to print. Not so, when printing sales invoices.

We also checked the REPORTS.DIC dictionary file, by accessing Report Writer, to ensure the purchase order report was not modified. Effectively, this was not the case. Puzzled by this situation, I called my good friend Rob Wagner over at Microsoft and explained what was going on. In formulating an approach to address the issue, Rob added a key to the Dex.ini - more on this tomorrow - that would allow him to debug what was happening when the template was generated.

To Rob's surprise, adding the Dex.ini key had no effect nor did it produce the debug file he was expecting. Then, the magical question came up... "Does you client have any third party products or add-ons installed that affect the POP module?" and the answer... "Yes, Project Accounting". This is when it all became clear to both of us where this was going.

As it turned out, the client is also using Project Accounting. However, the user entering the POs has no access to the Purchase Order Entry alternate window - hence was seeing the standard Microsoft Dynamics GP Purchase Order Entry window. However, according to security settings, the user had access to the alternate POP Purchase Order Blank Form report.

Access to alternate version of POP Purchase Order Blank Form

When the user prints the PO from the standard Purchase Order Entry window, GP would attempt to print the Project Accounting alternate purchase order report, but could not find a corresponding template.

Rob proceeded to explain that this behavior was by design. In essence, when a template cannot be found for an alternate version of an original Microsoft Dynamics GP report, the Dexterity code behind the Word Template functionality, will automatically render the report to HTML. Since html files are usually tied to Internet Explorer, this would cause that application to launch automatically.

The first tell-tell sign of a problem as described above lies in the Report Destination window defaulting the Report Type drop-down list to Standard, even though a template "exists" for the report being printed. In reality, the template you are seeing in Report Template Maintenance is the core Microsoft Dynamics GP report template and not the template for the alternate dictionary, in this case Project Accounting.

Solution

If using a third party product or add-on that contains an alternate versions of a core Microsoft Dynamics GP report, you will need to ensure that the template that is created corresponds to that dictionary or remove security to the alternate report.

However, and as luck would have it, I could not create a new template based on the existing POP Purchase Order Blank Form in the Microsoft Dynamics GP dictionary, because the two reports use a slighly different data set - the PA alternate report uses additional fields and tables not used by the standard report - but that's a tale for another time. In the mean time, I hope you find this article useful.

Until next post!

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

Read More

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/

Read More

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

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/

Read More

Enabling a Report Writer document as a Word Template

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/

Read More

Report Writer Week!

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/

Read More

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

"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/

Read More