Display Specific Line in Sales Order Processing

This will be a 2-for-1 post today as the example given solves a frequently asked question and was used to solve a customer issue.

The question I've seen a number of times before and been meaning to write about is: "How can I fill the Sales Order Processing scrolling window to a specific line?".  With Dexterity it isn't terribly difficult but is it possible with Visual Studio Tools?

The answer turns out to be "yes" by using a feature that Dynamics GP added with GP 10 or maybe 2010 (It is the Find Item feature - Drop Down bar | Find Item.  Anybody use this?).

The Problem

The problem that my customer was concerned about came about due to the Suggest Items feature for GP 2013.

When this feature is activated for an item, after you enter an item in Sales Transaction Entry, the "Suggest Sales Item Entry" window will open and allow the user to select any number of items from that list.   After selecting the items and hitting "OK", the window will enter the items in the back end, update the document totals, and then refill the scrolling window.

The concern was that in doing so, Dynamics GP moves focus to the Customer PO Number field and then refills the scrolling window from the top.  This forces the user to scroll back to the bottom of the list and re-select the Item Number and start entering data again which slows their users down.

The Reason Why

Before clearing & refilling the SOP scrolling window, the code moves focus to the Customer PO Number and then calls the Refill_Scroll of form SOP_Entry procedure.  In this case that wouldn't have been necessary but it would still refill the scrolling window which would remove focus from the window.  So either way, the customer finds this annoying.

The Solution

The obvious solution is that after the scrolling window is refilled (from the top), we should come behind and then have the window refilled again to the bottom on a new line so as to be able to quickly add the next item.

From Dexterity, we can use the "fill window" statement..  But for this to work right, we need it to be the SOP_LINE_WORK from the Sales Transaction Entry window.  Not a huge problem but one that typically often takes a trick to do.

From Visual Studio Tools, we don't have the same equivalent - it cannot fill a scrolling window.  Perhaps development will read my post and throw it in for the next version...

So thinking about the "Find Item" feature, I took a look to see how we did that.  And the function is:

GetLineItemSequenceReturn() of form SOP_Entry

function returns integer GetLineItemSequenceReturn;
in integer nCallerID;
in 'SOP Type' nSOPType;
in 'SOP Number' sSOPNumber;
in 'Component Sequence' nComponentSequence;
in 'Line Item Sequence' nLineItemSequence;
inout table SOP_LINE_WORK;

 

To be honest, it looks exactly like I'd expect.  The key fields for the table and the table buffer itself (with the range already set).

With Visual Studio Tools, using the right table buffer is a piece of cake - I love the feature that it allows us to specify the table buffer instance of a form!

So to refill the scroll window as we want, all we need to do is use a focus trigger when the Suggest Sales Item Entry window closes and call the procedure above.

Trigger Handling Script

void SopSuggestSalesItemEntry_CloseAfterOriginal(object sender, EventArgs e)       
{

    Microsoft.Dexterity.Applications.Dynamics.Forms.SopEntry.Functions.GetLineItemSequenceReturn.Invoke(
1,//SOP_ENTRY
Microsoft.Dexterity.Applications.Dynamics.Forms.SopEntry.SopEntry.SopTypeDatabase.Value, //The SOP Type = the real one vs how it shows in the SOP Type DDL
Microsoft.Dexterity.Applications.Dynamics.Forms.SopEntry.SopEntry.SopNumber.Value,//SOP Number
0, //component sequence, always 0 since we don't show component lines in SOP UI
Microsoft.Dexterity.Applications.Dynamics.Forms.SopEntry.SopEntry.LineItemSequence.Value,//line item sequence to display, in this case we want to show the "next" line
Microsoft.Dexterity.Applications.Dynamics.Forms.SopEntry.Tables.SopLineWork);//the SOP_LINE_WORK table. We want to use the one from SOP Entry itself which vstools allows us to do

//lastly, focus to the item number
Microsoft.Dexterity.Applications.Dynamics.Forms.SopEntry.SopEntry.LineScroll.ItemNumber.Focus(); 

}

In the example above, we pull the Line Item Sequence value from SOP Entry as that will be the "next line sequence number" for the next item entered.

The SopLineWork table is passed using the form table buffer.

After I wrote and tested the solution in VSTools, I thought it would be interesting to use the Support Debugging Tool.  This actually might have been difficult trying to get the SOP Entry table buffer to pass to the procedure.  But as it turns out, there is a trick to that as well.

In SOP Entry,  there are actually references to the SOP_HDR_WORK & SOP_LINE_WORK tables on the UI.  Table References are typically colored Dark Green on the UI.

SDT Code

out boolean OUT_Condition;

OUT_Condition = false;

if isopen(form SOP_Suggest_Sales_Item_Entry) then
GetLineItemSequenceReturn
(SOP_ENTRY,
'SOP Type Database' of window SOP_Entry of form SOP_Entry,
'SOP Number' of window SOP_Entry of form SOP_Entry,
0, {component seq}
'Line Item Sequence' of window SOP_Entry of form SOP_Entry,
table(SOP_SOLineState:'Table Reference' of window SOP_Entry of form SOP_Entry)
) of form SOP_Entry;

focus 'Item Number' of window Line_Scroll of form SOP_Entry;
end if;

 

The SDT Dexterity code above uses the same call as VSTools naturally.  The only real difference is the table buffer for the SOP_LINE_WORK table.

Notice that we use the SOP_SOLineState object to de-reference the table buffer and then pass it into the function. 

Getting the Code

Attached  to this post is a zip file that contains another zip file that holds the Visual Studio 2010 solution( with source) and the compiled assembly for GP 2013.  Just copy the SOPSuggestItemsFocus.dll into the GP\Addins folder and it should start working for you.

Also in that same zip file is the Script Debugger Tool xml that does the same thing.  So if you are using SDT, you can just import this solution and it will perform the same as the VSTools assembly solution.

PS: If GP crashes after you install the dll, refer to my recent blog post that explains why this happens and how to fix it.

Regards,

Patrick Roth
Senior Escalation Engineer, Dynamics GP

// Copyright © Microsoft Corporation.  All Rights Reserved.
// This code released under the terms of the
// Microsoft Public License (MS-PL, https://opensource.org/licenses/ms-pl.html.) 

 

Suggest_Item_Entry_Solutions.zip

Comments

• Anonymous
  February 24, 2014
  Simply brilliant! SDT implementation should be more than fine for my customers with the same issue.