Page 1 of 212

Archive for the ‘Support Debugging Tool’ Category

Support Debugging Tool Customization #11 – Restricting Salesperson ID for Existing Customers

Recently there was a support request in the forum,

http://social.microsoft.com/Forums/en-US/partnerdynamicsgp/thread/139b760a-5c63-4b16-b480-79f0a569075c

where the requirement was as below.

We want to modify the Customer Maintenance window to make the Salesperson ID field uneditable for existing records only.  I went into Modifier and made this field uneditable but that makes it uneditable each time the window opens.  We want the field to be available when creating a new customer – we just don’t want users to be able to change that field for existing customers.

In this article, I am going to post the details of how this customization can be achieved using Support Debugging Tool.

Version Information

Dynamics GP : 11.0.1914 (SP2)

Support Debugging Tool : 11.00.0016

Screenshots of the Configuration

Trigger #1 – Resource Tab

image

This is a trigger on the Display Existing Record Change – After Original on the Customer Maintenance window. This trigger will check if both the Customer Number and the Salesperson ID fields are populated with data, and if these fields are populated with values, we will lock the Salesperson ID field and disable the corresponding lookup button for the Salesperson ID field.

Trigger #1 – Customization Script

in string IN_OldValue;
in string IN_NewValue;
out boolean OUT_Condition;
 
OUT_Condition = false;
 
if isopen(form RM_Customer_Maintenance) then
	if not empty('Customer Number' of window 'RM_Customer_Maintenance' of form 'RM_Customer_Maintenance') and 
		not empty('Salesperson ID' of window 'RM_Customer_Maintenance' of form 'RM_Customer_Maintenance') then
		lock field 'Salesperson ID' of window 'RM_Customer_Maintenance' of form 'RM_Customer_Maintenance';
		disable field 'Lookup Button 6' of window 'RM_Customer_Maintenance' of form 'RM_Customer_Maintenance';
		OUT_Condition = true;
	else
		unlock field 'Salesperson ID' of window 'RM_Customer_Maintenance' of form 'RM_Customer_Maintenance';
		enable field 'Lookup Button 6' of window 'RM_Customer_Maintenance' of form 'RM_Customer_Maintenance';
		OUT_Condition = true;
	end if;
end if;

Trigger #2 – Resource Tab

image

This is a trigger on the Display Existing Record Change – After Original on the Customer Address Maintenance window. This trigger will check if the Customer Number, Address Code and the Salesperson ID fields are populated with data, and if these fields are populated with values, we will lock the Salesperson ID field and disable the corresponding lookup button for the Salesperson ID field.

Trigger #2 – Customization Script

in string IN_OldValue;
in string IN_NewValue;
out boolean OUT_Condition;
 
OUT_Condition = false;
 
if isopen(form RM_Customer_Address) then
	if not empty('Customer Number' of window 'RM_Customer_Address' of form 'RM_Customer_Address') and 
		not empty('Address Code' of window 'RM_Customer_Address' of form 'RM_Customer_Address') and
		not empty('Salesperson ID' of window 'RM_Customer_Address' of form 'RM_Customer_Address') then
		lock field 'Salesperson ID' of window 'RM_Customer_Address' of form 'RM_Customer_Address';
		disable field 'Lookup Button 8' of window 'RM_Customer_Address' of form 'RM_Customer_Address';
		OUT_Condition = true;
	else
		unlock field 'Salesperson ID' of window 'RM_Customer_Address' of form 'RM_Customer_Address';
		enable field 'Lookup Button 8' of window 'RM_Customer_Address' of form 'RM_Customer_Address';
		OUT_Condition = true;
	end if;
end if;

Configuration File Location

You can download the configuration for this requirement here.

Reference

Take a look at the article below which summarizes the usage of Support Debugging Tool with some real life examples. Great compilation by David! http://blogs.msdn.com/b/developingfordynamicsgp/archive/2011/08/05/using-the-support-debugging-tool-with-real-life-examples.aspx

You can get more details about the Support Debugging Tool at http://aka.ms/SDT

Hope this helps the community…

Until next post!

March 13, 2012 · veeyeskay · One Comment
Tags: , , , , , ,  · Posted in: Accounts Receivables, Customizations, Dynamics, Great Plains, Support Debugging Tool Total Views: 2,399

Support Debugging Tool–Build 16 Available Now!

Hi all

The all awaited Build 16 of the Support Debugging Tool is available now…and of course with loads and loads of new features and splendid enhancements. Some of the key additions to SDT is listed below.

  • Macro Recording Functionality
  • SQL Profile Tracing Functionality
  • Trigger Administration Functionality
  • Automation Functionality for Microsoft Support Usage

These are just some of them. Take a look at the article below for more information.

http://blogs.msdn.com/b/developingfordynamicsgp/archive/2012/01/06/support-debugging-tool-build-16-released.aspx

http://blogs.msdn.com/b/developingfordynamicsgp/archive/2009/08/07/support-debugging-tool.aspx

You can also download the Support Debugging Tool from Partnersource.

Support Debugging Tool for Dynamics GP 10

https://mbs.microsoft.com/partnersource/support/selfsupport/productreleases/supportdebuggingtool10.htm?printpage=false

Support Debugging Tool for Dynamics GP 2010

https://mbs.microsoft.com/partnersource/support/selfsupport/productreleases/MDGP2010_SupportDebuggingTool

I am sure this release would please many in the community with the cool features it has provided in this release!

Thanks David for the amazing release and I am happy to lend a little help in testing the awesome product!

Until next post!

January 6, 2012 · veeyeskay · One Comment
Tags: , , , , , , ,  · Posted in: Dynamics, Great Plains, Support Debugging Tool Total Views: 1,699

Support Debugging Tool Customization #10 – Credit Limit Check Skip in Receivables Transaction Entry (using SQL Execute in SDT)

Recently there was a support request in the forum,

http://social.microsoft.com/Forums/en-US/partnerdynamicsgp/thread/a3237a4f-fa4c-4603-8048-94cc0b2af467

where the requirement was as below.

Is there anything in Accounts Receivable that will allow a certain type of document (whatever that may be) bypass the Credit Limit Check? My client has a customer with a Credit Limit of $5000. They are additionally seeking a donation to a Charity from this customer for $10,000. They do not want the $10,000 invoice to be included in the Credit Limit Calculation. I know they could temporarily adjust the Credit Limit or they could setup a second Customer but is there any other way to get around the credit Limit in this case?”.

As a follow up to the earlier article titled Support Debugging Tool Customization #9 – Credit Limit Check Skip in Receivables Transaction Entry (using Native Dexterity Save Logic), I am going to post the logic of using SQL Execute method to handle the same requirement, in this article.

As you would be aware of, SQL Execute is an interface/API available inside Support Debugging Tool, where we can execute SQL scripts without the need for a database tool. With the help of David Musgrave, I have explored this a little bit and explained how to create parameterized SQL procedures in Support Debugging Tool and execute them dynamically in runtime by passing various values to the parameters.

Version Information

Dynamics GP : 11.0.1752 (SP2)

Support Debugging Tool : 11.00.0015

Screenshots of the Configuration

SQL Script ID #1 – Screenshot

image

This script is to update the credit limit for the customer as UNLIMITED. The SQL query for this ID is defined below.

--DECLARE @CUSTNMBR VARCHAR(15)
UPDATE  RM00101
SET     CRLMTTYP = 1 ,
        CRLMTAMT = 0 ,
        CRLMTPER = 0 ,
        CRLMTPAM = 0
WHERE   CUSTNMBR = @CUSTNMBR

SQL Script ID #2 – Screenshot

image

This script is to update the credit limit for the customer as UNLIMITED. The SQL script for this ID is given below.

--DECLARE @CUSTNMBR VARCHAR(15)
--DECLARE @CRLMTTYP INTEGER
--DECLARE @CRLMTAMT NUMERIC(19, 5)
--DECLARE @CRLMTPER INTEGER
--DECLARE @CRLMTPAM NUMERIC(19, 5)
UPDATE  RM00101
SET     CRLMTTYP = @CRLMTTYP ,
        CRLMTAMT = @CRLMTAMT ,
        CRLMTPER = @CRLMTPER ,
        CRLMTPAM = @CRLMTPAM
WHERE   CUSTNMBR = @CUSTNMBR

Note that I have commented the declaration lines in both the scripts above. This is key to note in this instance, since as I had said earlier, we would be calling this procedure with parameters passed at run time. Once these scripts are created, we can call these SQL script ID’s from other scripts in SDT. This will be explained in the subsequent sections.

Trigger #1 – Resource Tab

This is a trigger on the Customer Number Change – After Original on the Receivables Transaction Entry window. This is to capture the customer number and the document type into a parameter. Note the use of “MBS_Param_Set” to set the parameter values. You can use the Helper button to select the coding syntax for setting parameter values.

image_thumb[13]

Trigger #1 – Customization Script

in string IN_OldValue;
in string IN_NewValue;
out boolean OUT_Condition;
local string MBS_Parameter;
OUT_Condition = false;
if isopen(form RM_Sales_Entry) then
	if 'Document Type' of window 'RM_Sales_Entry' of form 'RM_Sales_Entry' = 2 then
		if not empty('Customer Number' of window RM_Sales_Entry of form RM_Sales_Entry) then
			call with name "MBS_Param_Set" in dictionary 5261,
				"CustNmbr",
				'Customer Number' of window RM_Sales_Entry of form RM_Sales_Entry;
			call with name "MBS_Param_Set" in dictionary 5261,
				"RMDocTypeAll",
				str('Document Type' of window 'RM_Sales_Entry' of form 'RM_Sales_Entry');
		end if;
	end if;
end if;

Trigger #2 – Resource Tab

image

This is a trigger on the Form Level Procedure for Credit Limit Check – Before Original. This is to capture the existing credit limit information into parameters in SDT and update the credit limit as UNLIMITED for the specific customer (which was retrieved from the parameter value captured earlier). Note the use of “MBS_Param_Get to retrieve the parameter values. You can use the Helper button to select the coding syntax for retrieving parameter values.

Also, note that I have helper functions for getting values from table fields using the Helper button. I have used this helper function to get the Credit Limit Type, Credit Limit Amount, Credit Limit Period and Credit Limit Period Amount and store them in parameters.

image

And then I call the SQL script ID which I have created above to update the credit limit for the customer as UNLIMITED. For this, I first call the procedure to load the SQL Script ID (i.e.) “MBS_Script_Load_SQL”, using the Helper functions. This procedure basically retrieves the SQL script for the ID into a text field. We then append append the parameter declarations and the values passed to these parameters before the query which is retrieved in the text variable as shown below. Then the final SQL script is executed using the “MBS_SQL_Check_Exists” procedure as shown below.

image

Trigger #2 – Customization Script

out 	boolean 	OUT_Condition;
local 	text 		MBS_Text_Field;
local 	integer 	MBS_Status;
 
local 	string		ls_CustNmbr;
local	string		ls_DocType;
local	integer		li_DocType;
local	text		lt_ParamQuery;
local 	string 		ls_Result;
local 	integer 	li_Pos;
local 	integer 	li_CredLimitType;
local 	currency 	lc_CredLimitAmt;
local 	integer 	li_CredLimitPeriod;
local 	currency 	lc_CredLimitPeriodAmt;
 
OUT_Condition = false;
 
if true then { Insert Condition Here }
	call with name "MBS_Param_Get" in dictionary 5261, "CustNmbr", ls_CustNmbr;
	call with name "MBS_Param_Get" in dictionary 5261, "RMDocTypeAll", ls_DocType;
	set li_DocType to integer(ls_DocType);
 
	if li_DocType = 2 and not empty(ls_CustNmbr) then
 
		{To get the current Credit Limit Type}
		call with name "MBS_Get_Table_Value1" in dictionary 5261,
			0 {Dict},
			"RM_Customer_MSTR" {Table},
			"'Credit Limit Type'" {Field},
			li_CredLimitType, MBS_Status, 1 {Index},
			"'Customer Number'", ls_CustNmbr;
		call with name "MBS_Param_Set" in dictionary 5261, "CredLimitType", str(li_CredLimitType);
 
		{To get the current Credit Limit Amount}
		call with name "MBS_Get_Table_Value1" in dictionary 5261,
			0 {Dict},
			"RM_Customer_MSTR" {Table},
			"'Credit Limit Amount'" {Field},
			lc_CredLimitAmt, MBS_Status, 1 {Index},
			"'Customer Number'", ls_CustNmbr;
		call with name "MBS_Param_Set" in dictionary 5261, "CredLimitAmt", str(lc_CredLimitAmt);
 
		{To get the current Credit Limit Period}
		call with name "MBS_Get_Table_Value1" in dictionary 5261,
			0 {Dict},
			"RM_Customer_MSTR" {Table},
			"'Credit Limit Period'" {Field},
			li_CredLimitPeriod, MBS_Status, 1 {Index},
			"'Customer Number'", ls_CustNmbr;
		call with name "MBS_Param_Set" in dictionary 5261, "CredLimitPeriod", str(li_CredLimitPeriod);
 
		{To get the current Credit Limit Period Amount}
		call with name "MBS_Get_Table_Value1" in dictionary 5261,
			0 {Dict},
			"RM_Customer_MSTR" {Table},
			"'Credit Limit Period Amount'" {Field},
			lc_CredLimitPeriodAmt, MBS_Status, 1 {Index},
			"'Customer Number'", ls_CustNmbr;
		call with name "MBS_Param_Set" in dictionary 5261, "CredLimitPeriodAmt", str(lc_CredLimitPeriodAmt);
 
		if li_CredLimitType <> 1 then
			clear lt_ParamQuery;
			{Load the SQL Script ID into a text variable}
			call with name "MBS_Script_Load_SQL" in dictionary 5261,
				"CREDLIMITCLEAR", MBS_Text_Field;
			{Set the variable declaration and values to the variables at run time}
			set lt_ParamQuery to lt_ParamQuery + "DECLARE @CUSTNMBR VARCHAR(15);" + char(13);
			set lt_ParamQuery to lt_ParamQuery + "SET @CUSTNMBR = '" + ls_CustNmbr + "';" + char(13);
			{Append the variable declaration string before the actual SQL script fetched from the SQL Script ID}
			set MBS_Text_Field to lt_ParamQuery + MBS_Text_Field;
			{Execute the SQL Script}
			call with name "MBS_SQL_Check_Exists" in dictionary 5261,
				MBS_Text_Field, false {Return Data}, false {Show Names}, MBS_Status;
 
		end if;
	end if;
	OUT_Condition = true;
end if;

Trigger #3 – Resource Tab

This is a trigger on the Form Level Procedure for Credit Limit Check – After Original. This is to reset the credit limit information back to the original values for the selected customer. Note the use of MBS_Param_DelAll procedure to delete any parameters which have been used in the process. You can use the Helper button to select the coding syntax for deleting parameter values.

image

Trigger #3 – Customization Script

OUT BOOLEAN OUT_Condition;
LOCAL text MBS_Text_Field;
LOCAL INTEGER MBS_Status;
 
LOCAL 	string		ls_CustNmbr;
LOCAL	string		ls_DocType;
LOCAL	string		ls_CredLimitType;
LOCAL	string		ls_CredLimitAmt;
LOCAL	string		ls_CredLimitPeriod;
LOCAL	string		ls_CredLimitPeriodAmt;
LOCAL	INTEGER		li_DocType;
LOCAL	INTEGER		li_CredLimitType;
LOCAL	currency	lc_CredLimitAmt;
LOCAL	INTEGER		li_CredLimitPeriod;
LOCAL	currency	lc_CredLimitPeriodAmt;
LOCAL	text		lt_ParamQuery;
 
OUT_Condition = FALSE;
 
IF TRUE THEN { INSERT Condition Here }
	{GET the parameter VALUES}
	CALL WITH name "MBS_Param_Get" IN dictionary 5261, "CustNmbr", ls_CustNmbr;
	CALL WITH name "MBS_Param_Get" IN dictionary 5261, "RMDocTypeAll", ls_DocType;
	CALL WITH name "MBS_Param_Get" IN dictionary 5261, "CredLimitType", ls_CredLimitType;
	CALL WITH name "MBS_Param_Get" IN dictionary 5261, "CredLimitAmt", ls_CredLimitAmt;
	CALL WITH name "MBS_Param_Get" IN dictionary 5261, "CredLimitPeriod", ls_CredLimitPeriod;
	CALL WITH name "MBS_Param_Get" IN dictionary 5261, "CredLimitPeriodAmt", ls_CredLimitPeriodAmt;
 
	SET li_DocType TO INTEGER(ls_DocType);
	SET li_CredLimitType TO INTEGER(ls_CredLimitType);
	SET lc_CredLimitAmt TO VALUE(ls_CredLimitAmt);
	SET li_CredLimitPeriod TO INTEGER(ls_CredLimitPeriod);
	SET lc_CredLimitPeriodAmt TO VALUE(ls_CredLimitPeriodAmt);
 
	IF li_DocType = 2 AND NOT empty(ls_CustNmbr) THEN
		clear lt_ParamQuery;
		{LOAD the SQL Script ID}
		CALL WITH name "MBS_Script_Load_SQL" IN dictionary 5261,
			"CREDLIMITRESET", MBS_Text_Field;
		{Setting the dynamic parameter query string}
		SET lt_ParamQuery TO lt_ParamQuery + "DECLARE @CUSTNMBR VARCHAR(15);" + CHAR(13);
		SET lt_ParamQuery TO lt_ParamQuery + "DECLARE @CRLMTTYP INTEGER;" + CHAR(13);
		SET lt_ParamQuery TO lt_ParamQuery + "DECLARE @CRLMTAMT NUMERIC(19, 5);" + CHAR(13);
		SET lt_ParamQuery TO lt_ParamQuery + "DECLARE @CRLMTPER INTEGER;" + CHAR(13);
		SET lt_ParamQuery TO lt_ParamQuery + "DECLARE @CRLMTPAM NUMERIC(19, 5);" + CHAR(13);
		SET lt_ParamQuery TO lt_ParamQuery + "SET @CUSTNMBR = '" + ls_CustNmbr + "';" + CHAR(13);
		SET lt_ParamQuery TO lt_ParamQuery + "SET @CRLMTTYP = " + str(li_CredLimitType) + ";" + CHAR(13);
		SET lt_ParamQuery TO lt_ParamQuery + "SET @CRLMTAMT = " + str(lc_CredLimitAmt) + ";" + CHAR(13);
		SET lt_ParamQuery TO lt_ParamQuery + "SET @CRLMTPER = " + str(li_CredLimitPeriod) + ";" + CHAR(13);
		SET lt_ParamQuery TO lt_ParamQuery + "SET @CRLMTPAM = " + str(lc_CredLimitPeriodAmt) + ";" + CHAR(13);
		{Appending the dynamic parameter query string TO the actual query}
		SET MBS_Text_Field TO lt_ParamQuery + MBS_Text_Field;
		{EXECUTE the SQL script}
		CALL WITH name "MBS_SQL_Check_Exists" IN dictionary 5261,
			MBS_Text_Field, FALSE {RETURN DATA}, FALSE {SHOW Names}, MBS_Status;
	END IF;
	CALL WITH name "MBS_Param_DelAll" IN dictionary 5261;
	OUT_Condition = TRUE;
END IF;

Note: The earlier post was done using Dexterity code logic and this version was done using SQL Execute. It does not make a difference if either option is chosen. We have just provided an insight into this functionality and the use of SQL Execute in Support Debugging Tool. This type is generally very useful when you want to update tables which are not GP related, since the other options will not be viable to update non GP tables in SQL. As said earlier, the method to be used will differ on a case to case basis, and the appropriate choice can be used as and when needed. Thanks again to David, for guiding me through each step in utilizing Support Debugging Tool to help the community.

Configuration File Location

You can download the configuration for this requirement here.

Reference

Take a look at the article below which summarizes the usage of Support Debugging Tool with some real life examples. Great compilation by David! http://blogs.msdn.com/b/developingfordynamicsgp/archive/2011/08/05/using-the-support-debugging-tool-with-real-life-examples.aspx

Hope this helps the community…

Until next post!

November 4, 2011 · veeyeskay · 5 Comments
Tags: , , , , , , , , , , ,  · Posted in: Accounts Receivables, Customizations, Dynamics, Great Plains, Support Debugging Tool Total Views: 3,678

Support Debugging Tool Customization #9 – Credit Limit Check Skip in Receivables Transaction Entry (using Native Dexterity Save Logic)

Recently there was a support request in the forum,

http://social.microsoft.com/Forums/en-US/partnerdynamicsgp/thread/a3237a4f-fa4c-4603-8048-94cc0b2af467

where the requirement was as below.

Is there anything in Accounts Receivable that will allow a certain type of document (whatever that may be) bypass the Credit Limit Check? My client has a customer with a Credit Limit of $5000.  They are additionally seeking a donation to a Charity from this customer for $10,000.  They do not want the $10,000 invoice to be included in the Credit Limit Calculation.  I know they could temporarily adjust the Credit Limit or they could setup a second Customer but is there any other way to get around the credit Limit in this case?”.

Since this is not an out of the box functionality, it needs to be customized. Assuming that the customer does not want the credit limit check for Debit Memos, the design that I thought of was to update the credit limit information for the customer by setting his credit limit to unlimited, before the credit limit validation procedure is called (taking a backup of the existing values), and once the validation was competed, I will update the original credit limit information back for the customer. This update happened only if the document type was Debit Memos.

I decided to take this up as a Support Debugging Tool task and planned to achieve it using 2 methods.

  • Using native Dexterity code for updating the customer record (using the “save record” command).
  • Using SQL Execute functionality in Support Debugging Tool

Another functionality of SDT which I have explored in this task, is the use of parameter collections in SDT, where we can set the parameters in one procedure in SDT and retrieve them from another procedure, thus explaining the feature of how to pass parameters from one procedure into another using Support Debugging Tool.

In this article, I am going to post the native Dexterity method and how it was achieved.

Version Information

Dynamics GP : 11.0.1752 (SP2)

Support Debugging Tool : 11.00.0015

Screenshots of the Configuration

Trigger #1 – Resource Tab

This is a trigger on the Customer Number Change – After Original on the Receivables Transaction Entry window. This is to capture the customer number and the document type into a parameter. Note the use of “MBS_Param_Set to set the parameter values. You can use the Helper button to select the coding syntax for setting parameter values.

image

Trigger #1 – Customization Script

in string IN_OldValue;
in string IN_NewValue;
out boolean OUT_Condition;
local string MBS_Parameter;
OUT_Condition = false;
if isopen(form RM_Sales_Entry) then
	if 'Document Type' of window 'RM_Sales_Entry' of form 'RM_Sales_Entry' = 2 then
		if not empty('Customer Number' of window RM_Sales_Entry of form RM_Sales_Entry) then
			call with name "MBS_Param_Set" in dictionary 5261,
				"CustNmbr",
				'Customer Number' of window RM_Sales_Entry of form RM_Sales_Entry;
			call with name "MBS_Param_Set" in dictionary 5261,
				"RMDocTypeAll",
				str('Document Type' of window 'RM_Sales_Entry' of form 'RM_Sales_Entry');
		end if;
	end if;
end if;
MBS_Parameter = "Value";
call with name "MBS_Param_Set" in dictionary 5261, "Variable", MBS_Parameter;

Trigger #2 – Resource Tab

This is a trigger on the Form Level Procedure for Credit Limit Check – Before Original. This is to capture the existing credit limit information into parameters in SDT and update the credit limit as UNLIMITED for the specific customer (which was retrieved from the parameter value captured earlier). Note the use of “MBS_Param_Get” to retrieve the parameter values. You can use the Helper button to select the coding syntax for retrieving parameter values.

image

Trigger #2 – Customization Script

out 	boolean	OUT_Condition;
local 	string 	MBS_Parameter;
 
local 	string	ls_CustNmbr;
local	string	ls_DocType;
local	integer	li_DocType;
 
OUT_Condition = false;
if true then { Insert Condition Here }
	call with name "MBS_Param_Get" in dictionary 5261, "CustNmbr", ls_CustNmbr;
	call with name "MBS_Param_Get" in dictionary 5261, "RMDocTypeAll", ls_DocType;
	set li_DocType to integer(ls_DocType);
 
	if li_DocType = 2 and not empty(ls_CustNmbr) then
		clear table RM_Customer_MSTR;
		set 'Customer Number' of table RM_Customer_MSTR to ls_CustNmbr;
		change table RM_Customer_MSTR by number 1;
		if err() = OKAY then
			if 'Credit Limit Type' of table RM_Customer_MSTR <> 1 then
				call with name "MBS_Param_Set" in dictionary 5261, "CredLimitType", str('Credit Limit Type' of table RM_Customer_MSTR);
				call with name "MBS_Param_Set" in dictionary 5261, "CredLimitAmt", str('Credit Limit Amount' of table RM_Customer_MSTR);
				call with name "MBS_Param_Set" in dictionary 5261, "CredLimitPeriod", str('Credit Limit Period' of table RM_Customer_MSTR);
				call with name "MBS_Param_Set" in dictionary 5261, "CredLimitPeriodAmt", str('Credit Limit Period Amount' of table RM_Customer_MSTR);
				set 'Credit Limit Type' of table RM_Customer_MSTR to 1;
				set 'Credit Limit Amount' of table RM_Customer_MSTR to 0;
				set 'Credit Limit Period' of table RM_Customer_MSTR to 0;
				set 'Credit Limit Period Amount' of table RM_Customer_MSTR to 0;
				save table RM_Customer_MSTR;
			end if;
		end if;
	end if;
	OUT_Condition = true;
end if;

 

Trigger #3 – Resource Tab

This is a trigger on the Form Level Procedure for Credit Limit Check – After Original. This is to reset the credit limit information back to the original values for the selected customer. Note the use of “MBS_Param_DelAll” procedure to delete any parameters which have been used in the process. You can use the Helper button to select the coding syntax for deleting parameter values.

image

Trigger #3 – Customization Script

OUT 	BOOLEAN		OUT_Condition;
LOCAL 	string 		MBS_Parameter;
 
LOCAL 	string		ls_CustNmbr;
LOCAL	string		ls_DocType;
LOCAL	string		ls_CredLimitType;
LOCAL	string		ls_CredLimitAmt;
LOCAL	string		ls_CredLimitPeriod;
LOCAL	string		ls_CredLimitPeriodAmt;
LOCAL	INTEGER		li_DocType;
LOCAL	INTEGER		li_CredLimitType;
LOCAL	currency	lc_CredLimitAmt;
LOCAL	INTEGER		li_CredLimitPeriod;
LOCAL	currency	lc_CredLimitPeriodAmt;
 
OUT_Condition = FALSE;
IF TRUE THEN { INSERT Condition Here }
	CALL WITH name "MBS_Param_Get" IN dictionary 5261, "CustNmbr", ls_CustNmbr;
	CALL WITH name "MBS_Param_Get" IN dictionary 5261, "RMDocTypeAll", ls_DocType;
	CALL WITH name "MBS_Param_Get" IN dictionary 5261, "CredLimitType", ls_CredLimitType;
	CALL WITH name "MBS_Param_Get" IN dictionary 5261, "CredLimitAmt", ls_CredLimitAmt;
	CALL WITH name "MBS_Param_Get" IN dictionary 5261, "CredLimitPeriod", ls_CredLimitPeriod;
	CALL WITH name "MBS_Param_Get" IN dictionary 5261, "CredLimitPeriodAmt", ls_CredLimitPeriodAmt;
	SET li_DocType TO INTEGER(ls_DocType);
	SET li_CredLimitType TO INTEGER(ls_CredLimitType);
	SET lc_CredLimitAmt TO VALUE(ls_CredLimitAmt);
	SET li_CredLimitPeriod TO INTEGER(ls_CredLimitPeriod);
	SET lc_CredLimitPeriodAmt TO VALUE(ls_CredLimitPeriodAmt);
 
	IF li_DocType = 2 AND NOT empty(ls_CustNmbr) THEN
		clear TABLE RM_Customer_MSTR;
		SET 'Customer Number' OF TABLE RM_Customer_MSTR TO ls_CustNmbr;
		CHANGE TABLE RM_Customer_MSTR BY NUMBER 1;
		IF err() = OKAY THEN
			SET 'Credit Limit Type' OF TABLE RM_Customer_MSTR TO li_CredLimitType;
			SET 'Credit Limit Amount' OF TABLE RM_Customer_MSTR TO lc_CredLimitAmt;
			SET 'Credit Limit Period' OF TABLE RM_Customer_MSTR TO li_CredLimitPeriod;
			SET 'Credit Limit Period Amount' OF TABLE RM_Customer_MSTR TO lc_CredLimitPeriodAmt;
			save TABLE RM_Customer_MSTR;
		END IF;
	END IF;
	CALL WITH name "MBS_Param_DelAll" IN dictionary 5261;
	OUT_Condition = TRUE;
END IF;

Configuration File Location

You can download the configuration for this requirement here.

Reference

Take a look at the article below which summarizes the usage of Support Debugging Tool with some real life examples. Great compilation by David! http://blogs.msdn.com/b/developingfordynamicsgp/archive/2011/08/05/using-the-support-debugging-tool-with-real-life-examples.aspx

Hope this helps the community…

Until next post!

November 3, 2011 · veeyeskay · 9 Comments
Tags: , , , , , , , , , ,  · Posted in: Customizations, Dynamics, Great Plains, Support Debugging Tool Total Views: 5,741

Support Debugging Tool Customization #8 – Displaying Long Item Descriptions on SOP Blank Invoice

This article is based on a recent support request on the SOP Blank Invoice Report form. The Item Description on the report was just 60 characters and the actual item description was about 100 characters. This resulted in the item description getting truncated.

I have written this article using the article titled “How to display more than 80 characters of an Extender Long String field in reports using the Support Debugging Tool” written by David Musgrave as a base.

Version Information

Dynamics GP : 11.0.1752 (SP2)

Support Debugging Tool : 11.00.0015

Screenshots of the Configuration

Create a Runtime Execute script block with the code given below with the script ID as ITEMDESC.

image

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;
local integer MBS_Status;
local string MBS_String_Value;
local string MBS_String_Value1;
local integer MBS_Integer_Value2;
local long MBS_Long_Value3;
local long MBS_Long_Value4;
 
{Declarations}
local string ls_ItemDesc;
 
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_SequenceTwo = currency(value(MBS_String));
call with name "MBS_Param_Get" in dictionary 5261, "SequenceTwo", MBS_String;
MBS_SequenceOne = 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 }
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 'Component Sequence' of table SOP_LINE_WORK to MBS_SequenceOne;
set 'Line Item Sequence' of table SOP_LINE_WORK to MBS_SequenceTwo;
get table SOP_LINE_WORK by number 1;
if err() = OKAY then
	set ls_ItemDesc to 'Item Description' of table SOP_LINE_WORK;
end if;
set MBS_TableLineString to RW_ParseString(ls_ItemDesc, 50, MBS_Control);
{ Add your code above here }
 
call with name "MBS_Param_Set" in dictionary 5261, "TableLineString", MBS_TableLineString;

Then modify the SOP Blank Invoice Report and create the following Calculated Fields.

Calculated Field Name : ComponentSequence

Calculated Field Type : Currency

Formula : SOP_LINE_WORK.Component Sequence * 1.00000

Calculated Field Name : LineItemSequence

Calculated Field Type : Currency

Formula : SOP_LINE_WORK.Line Item Sequence * 1.00000

And finally create 2 calculated fields for Item Descriptions as explained below.

Calculated Field Name : ItemDescription1

Calculated Field Type : String

Formula : FUNCTION_SCRIPT(  rw_TableLineString  5261  “ITEMDESC”  SOP_LINE_WORK.SOP Number  SOP_LINE_WORK.SOP Type  (C) LineItemSequence  (C) ComponentSequence  1  )

Calculated Field Name : ItemDescription2

Calculated Field Type : String

Formula : FUNCTION_SCRIPT( rw_TableLineString 5261 “ITEMDESC” SOP_LINE_WORK.SOP Number SOP_LINE_WORK.SOP Type (C) LineItemSequence (C) ComponentSequence 2 )

In the formulae, (C) LineItemSequence is the calculated field which we have created for the Line Item Sequence and (C) ComponentSequence is the calculated field which we have created for the Component Sequence field.

Note that for the first calculated field for Item Description, we are passing the fifth parameter for the rw_TableLineString function as 1 and for the second calculated field, we are passing the fifth parameter as 2. This will return the full item description split into 2 calculated fields. If you have a custom field where you have captured a longer description, you can add additional description fields and pass the appropriate index value to the function to return the value to the appropriate calculated field.

Once the report is saved and access granted to the modified report, the report prints as shown below.

image

Update – 11/01/2011: Based on recommendation from David Musgrave, I have split the Item Description to 50 characters for each field in the code set MBS_TableLineString to RW_ParseString(ls_ItemDesc, 50, MBS_Control); . This makes it more readable and evenly distributed characters. The configuration file has been updated with the specific change.

You can download the configuration file for this customization here.

Reference

Take a look at the article below which summarizes the usage of Support Debugging Tool with some real life examples. Great compilation by David! http://blogs.msdn.com/b/developingfordynamicsgp/archive/2011/08/05/using-the-support-debugging-tool-with-real-life-examples.aspx

Hope this helps the community…

Until next post!

October 31, 2011 · veeyeskay · 4 Comments
Tags: , , , , , , , ,  · Posted in: Customizations, Dynamics, Great Plains, Support Debugging Tool Total Views: 2,464

Support Debugging Tool Customization #7 – Receiving Unit Cost Threshold Validation

Based on a recent requests on the community, where the requirement was to validate that the unit cost entered in the Receiving Transaction Entry window is not more (or) less than a specified threshold of the Unit Cost entered in the respective PO line.

I have used Support Debugging Tool to handle this requirement. I have added this validation on the following windows.

  • Receivings Transaction Entry
  • Receivings Item Detail Entry
  • Purchasing Invoice Entry

Version Information

Dynamics GP : 11.0.1752 (SP2)

Support Debugging Tool : 11.00.0015

Screenshots of the Configuration

Trigger #1 – Resource Tab

This is a trigger on the Unit Cost Change – Before Original on the Receiving Transaction Entry scrolling window.

image

Trigger #1 – Actions Tab

If the validation fails, we will reject further execution of the GP script for the Unit Cost field, and we will set the old value to the Unit Cost field and leave the focus back to the Unit Cost field.

image

Trigger #1 – Customization Script

in string IN_OldValue;
in string IN_NewValue;
out boolean OUT_Condition;
 
local 'PO Number' 	l_PONo;
local 'Item Number'	l_ItemNo;
local Ord		l_Ord;
local 'Unit Cost'	l_UnitCostMin, l_UnitCostMax;
local currency		l_Threshold;
 
OUT_Condition = false;
 
set l_Threshold to 0.1;
 
if isopen(form POP_Receivings_Entry) then
	set l_PONo to 'PO Number' of window 'Line_Scroll' of form 'POP_Receivings_Entry';
	set l_ItemNo to 'Item Number' of window 'Line_Scroll' of form 'POP_Receivings_Entry';
	set l_Ord to 'PO Line Number' of window 'Line_Scroll' of form 'POP_Receivings_Entry';
	clear table POP_POLine;
	set 'Item Number' of table POP_POLine to l_ItemNo;
	set 'PO Number' of table POP_POLine to l_PONo;
	set 'Ord' of table POP_POLine to l_Ord;
	get table POP_POLine by number 2;
	if err() = OKAY then
		set l_UnitCostMin to 'Unit Cost' of table POP_POLine;
		set l_UnitCostMin to l_UnitCostMin - round((l_UnitCostMin*l_Threshold),
			DECIMALRIGHT, ROUNDMODE_HALF_UP, 2);
		set l_UnitCostMax to 'Unit Cost' of table POP_POLine;
		set l_UnitCostMax to l_UnitCostMax + round((l_UnitCostMax*l_Threshold),
			DECIMALRIGHT, ROUNDMODE_HALF_UP, 2);
		if ('Unit Cost' of window 'Line_Scroll' of form 'POP_Receivings_Entry' < l_UnitCostMin or
			'Unit Cost' of window 'Line_Scroll' of form 'POP_Receivings_Entry' > l_UnitCostMax) then
			warning "The unit cost is beyond the threshold defined for this item in the purchase order!";
			OUT_Condition = true;
		end if;
	end if;
end if;

Trigger #2 – Resource Tab

This is a trigger on the Extended Cost Change – Before Original on the Receiving Transaction Entry Scrolling window.

image

Trigger #2 – Actions Tab

If the validation fails, we will reject further execution of the GP script for the Extended Cost field, and we will set the old value to the Extended Cost field and leave the focus back to the Extended Cost field.

image

Trigger#2 – Customization Script

in string IN_OldValue;
in string IN_NewValue;
out boolean OUT_Condition;
 
local 'PO Number' 		l_PONo;
local 'Item Number'		l_ItemNo;
local Ord			l_Ord;
local 'Unit Cost'		l_UnitCostMin, l_UnitCostMax, l_CalcUnitCost;
local 'Extended Cost'		l_ExtdCost;
local QTY			l_QtyShipped;
local currency			l_Threshold;
 
OUT_Condition = false;
 
set l_Threshold to 0.1;
 
if isopen(form POP_Receivings_Entry) then
	set l_PONo to 'PO Number' of window 'Line_Scroll' of form 'POP_Receivings_Entry';
	set l_ItemNo to 'Item Number' of window 'Line_Scroll' of form 'POP_Receivings_Entry';
	set l_Ord to 'PO Line Number' of window 'Line_Scroll' of form 'POP_Receivings_Entry';
	clear table POP_POLine;
	set 'Item Number' of table POP_POLine to l_ItemNo;
	set 'PO Number' of table POP_POLine to l_PONo;
	set 'Ord' of table POP_POLine to l_Ord;
	get table POP_POLine by number 2;
	if err() = OKAY then
		set l_UnitCostMin to 'Unit Cost' of table POP_POLine;
		set l_UnitCostMin to l_UnitCostMin - (l_UnitCostMin*l_Threshold);
		set l_UnitCostMax to 'Unit Cost' of table POP_POLine;
		set l_UnitCostMax to l_UnitCostMax + (l_UnitCostMax*l_Threshold);
		set l_ExtdCost to 'Extended Cost' of window 'Line_Scroll' of form 'POP_Receivings_Entry';
		set l_QtyShipped to 'QTY Shipped' of window 'Line_Scroll' of form 'POP_Receivings_Entry';
		set l_CalcUnitCost to round((l_ExtdCost/l_QtyShipped),
			DECIMALRIGHT, ROUNDMODE_HALF_UP, 2);
		if (l_CalcUnitCost < l_UnitCostMin or
			l_CalcUnitCost > l_UnitCostMax) then
			warning "The unit cost is beyond the threshold defined for this item in the purchase order!";
			OUT_Condition = true;
		end if;
	end if;
end if;

Assumptions

For the  purpose of this customization, I have assumed a threshold of 10% (i.e.) the unit cost entered in the Receiving Transaction Entry for a line can be more or less by 10% but not beyond. You can change this to any other value needed based on business needs. You can even have the threshold defined in a custom table and fetch it from the table.

Things To Remember

The above code example is for the Receiving Transactions Entry window. However, we will also have to replicate a similar logic on the Receivings Item Detail Entry window for both the Unit Cost and Extended Cost field, since the user can enter/change the unit cost and extended cost on this window as well.

Configuration File Location

You can download the configuration for this requirement here. This file has the triggers for both the windows mentioned above.

Reference

Take a look at the article below which summarizes the usage of Support Debugging Tool with some real life examples. Great compilation by David! http://blogs.msdn.com/b/developingfordynamicsgp/archive/2011/08/05/using-the-support-debugging-tool-with-real-life-examples.aspx

Hope this helps the community…

Until next post!

October 8, 2011 · veeyeskay · 3 Comments
Tags: , , , , , , , ,  · Posted in: Customizations, Dynamics, Great Plains, Support Debugging Tool Total Views: 2,009

Support Debugging Tool Customization #6 – Removing Voided Documents from Customer Statement

Based on a recent support request, I have decided to post yet another article which utilizes the Support Debugging Tool to achieve the above requirement, where in the voided documents do not appear in the Customer Statement.

For this requirement, I have customized the RM Statement On Blank Paper version of the Customer Statement. The other versions can also be modified accordingly.

Version Information

Dynamics GP : 11.0.1752 (SP2)

Support Debugging Tool : 11.00.0015

Screenshots of the Configuration

Create a Runtime Execute script block with the code given below with the script ID as STMTVOIDEXCL.

image

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;
 
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 }
release table RM_OPEN;
clear table RM_OPEN;
set 'RM Document Type-All' of table RM_OPEN to MBS_Type;
set 'Document Number' of table RM_OPEN to MBS_Number;
get table RM_OPEN by number 4;
if err() = OKAY then
	if 'Void Status' of table RM_OPEN = 1 then
		set MBS_TableLineString to "";
	else
		set MBS_TableLineString to "V";
	end if;
else
	set MBS_TableLineString to "V";
end if;
{ Add your code above here }
 
call with name "MBS_Param_Set" in dictionary 5261, "TableLineString", MBS_TableLineString;

Then modify the RM Statement On Blank Paper report and create a calculated field, as explained below, which calls the custom Report Writer function for which we have created the script block above.

Calculated Field Name : Valid

Result Type : String

Expression Type : Calculated

image

The formula for this calculated field is as shown below.

FUNCTION_SCRIPT(  rw_TableLineString  5261  “STMTVOIDEXCL”  RM_Statements_TRX_TEMP.Document Number  RM_Statements_TRX_TEMP.RM Document Type-All  0.00000  0.00000  1  )

Now, place the field on the body section of the report layout and make the field invisible.

image

And then go to the Section Properties and define the following setting for the body section, to hide the body conditions whenever the calculated field Valid is empty. Our custom runtime script which we have written in Support Debugging Tool will set this field value to V if it’s a valid record and will make this field blank when it is a voided record, thus hiding the voided records from the report.

image

Configuration File Download

You can download the configuration xml file here.

Reference

Take a look at the article below which summarizes the usage of Support Debugging Tool with some real life examples. Great compilation by David! http://blogs.msdn.com/b/developingfordynamicsgp/archive/2011/08/05/using-the-support-debugging-tool-with-real-life-examples.aspx

Hope this helps the community…

Until next post!

August 18, 2011 · veeyeskay · 2 Comments
Tags: , , ,  · Posted in: Accounts Receivables, Customizations, Dynamics, Great Plains, Support Debugging Tool Total Views: 1,845