Duplicate SOP Master number in Dynamics GP

The credit card fulfilment add in that I wrote charges cards using sage pay API, from the GP screens or our custom SOP Fulfilment software, when the goods are despatched on a sales order.

In order for the charges to be tracked as the sales document migrates from Sales order to Invoice and subsequent fulfilments I utilise the master number of the order. However it turns out that the master number can end up getting shared by more than one document.

Master Numbers – what are they?

Master numbers can be enabled in the SOP setup screen.

SOPSetup

When ever a new document is created from a source document, they are tied together with a common master number. The stored procedure:taSopGetMasterNumber in the company database serves us with the next master number from number in this setup screen when ever a new sales document is created without getting derived from another document.

You can use master numbers in SOP Document enquiry and reporting to see all related documents as the master number ties them all together.

Our Issue

Somehow we have found that some of our sales documents have ended up sharing master numbers with unrelated documents. We have seen this with the SOP number itself too but there it is more obvious.

To find the maser numbers that are causing a problem I put together the following script that will work on SQL server 2005+. Note that we don't use back order document types so only one sales order document exists per master number according to our business logic.

WHERE ORIGTYPE=0 should help identify them if you do use back order documents, but the query will not use the indexes on the tables and thus will take a long time to execute.

-- Script to identify duplicate Master Numbers 
--  on Dynamics GP SOP Documents
With WorkHistUnion (MSTRNUMB, SOPNUMBE )as
(SELECT MSTRNUMB,SOPNUMBE  FROM SOP10100 WHERE SOPTYPE=2
UNION ALL
SELECT MSTRNUMB,SOPNUMBE FROM SOP30200 WHERE SOPTYPE=2)
SELECT  MSTRNUMB, COUNT(MSTRNUMB)from WorkHistUnionGROUP 
BY MSTRNUMBHAVING COUNT(MSTRNUMB)>1ORDER BY MSTRNUM
 

Trying this on one of our GP9 companies I got (278 row(s) affected). So we have 278 instances of sales documents sharing master numbers with unrelated sales orders. Now I have introduced a check that looks for this senario and uses the customer CUSTNMBR as a key when charging cards.

Hopefully this should stop the wrong customer getting charged for a despatch of goods – bug squished!

Why do we get this situation? Dynamics GP does not lean very much on SQL server for database integrity. This is due to the heritage of the product, rooted in DBISAM, it has never used the database to ensure integrity. SQL server is quite capable through the correct transaction handling and constraint indexes of ensuring the master numbers are not shared, but sadly it has never been written into the database.There must be some holes in the application that allows this to happen in a similar way that our telesales team sometimes manage to get the same SOP number as each other.

Edit 2011

Some more web references have shown up since 2009 when I wrote this originally, the reason behind this happening can be found in these references too:

SOP Master Numbers not being assigned properly

SOP Master Numbers not being assigned properly (Dynamics community site)

Alternative Get SOP master number script (stored proc)

Dynamics GP slow to login or open forms, other users ok

Original post:14th March 2009

Updated 2016:

I notice that Ian had a similar problem that this solved too, see his post here: http://www.azurecurve.co.uk/2015/03/slow-opening-windows-in-microsoft-dynamics-gp/

Updated 2015:

GP offers a cache clear button (Remove Entries), under user preferences, I don’t think it existed/didn’t work or I didn’t know about it when this post was written, hence the drastic measures of removing the cache files. It would be wise to check the size of the cache files before and after “Removing Entries” to see if the size really does decrease. I would still advocate some audit/enforcing scheduled SQL script as mentioned later in the post to protect users from setting values for auto complete too high, especially in installations with very large numbers of items or customers/suppliers etc.


AutoComplete2

AutoComplete Setup is found from the user preference window, by clicking on AutoComplete button.

autocomplete
 
The problem report as reported:
Goods receiving, purchasing and accounts users all report some GP forms taking a very long time to open. Log in as admin or some alternative user and the problem does not occur. It was also observed that when a user’s network profile was deleted and recreated the problem went away (discovered by accident due to having to do this for other reasons and finding it solved this problem).
For information the company has over seventy four thousand items setup in inventory.

GPAutoComplete

Above: AutoComplete is a great feature that I welcomed but now is causing problems

Found the solution

The clue to the solution was this post: How to troubleshoot slow performance in Microsoft Dynamics GP [login required] 
More...

Smart Connect for Dynamics GP Webinar

I attended a webinar today hosted by Touchstone’s Dominic Houlbrooke-Bowers, about Smart Connect for Dynamics GP

Summary

There are two ways to summarise this product from this demo (i’ve not yet read more);

Replacement for integration manager using eConnect to enforce the busines rules, providing a richer and much faster experience than integration manager.
OR
A power user graphical user interface for eConnect

It has some very powerful extra features too like  push from internet placed excel or info path forms to web services and into GP.

Product description

More...



UPS World Ship XML Import from Dynamics GP

Problem

The Sales Order Fulfilment (SOP) software I wrote for Microsoft Dynamics GP, deals with multiple Dynamics GP companies. You can choose the company and fulfil any available pick lists for sales orders or invoices from that company. The software implements a least cost parcel routing engine. If it decides to route to UPS or TNT carriers we wish the software to ensure that that carrier invoices the correct originating company, avoiding the necessity for intercompany transactions in the accounting system to apportion costs.

The parcel details are sent to the UPS World Ship software as XML files, generated from an XSLT against the order tables SOP10100 and SOP10200 and several custom tables for pick lists and despatch records.

History

The XML Import has been something we have used for many years, since World Ship 5.0, I think we are on 11 now. However when we enquired about having multiple shipper billing accounts it was not possible without a separate instance of world ship for each carrier account. It was something that was mooted as a feature of the next version.

Last Week

Time has moved on and UPS upgraded us recently to the current version of World Ship, so I revisited the problem.

I investigated the Openshipments.xdr schema file for the new version of World Ship to see what had changed. I found a new element definition as shown below for the shipper UpsAccountNumber, i.e. the place the cost for the shipment should be invoiced to.

<ElementType name = "Shipper" content = "eltOnly" order = "seq" model = "closed">
<element type = "UpsAccountNumber" minOccurs = "0" maxOccurs = "1"/>
</ElementType>

I then changed our XSLT to add a node in our outputted XML, and a parameter to pass into the XSLT so that I may pass the UPS account number to the XSLT.

<Shipper>
<UpsAccountNumber><xsl:value-of select="normalize-space($AccountNo)"/></UpsAccountNumber>
</Shipper>  

After ensuring the accounts were set up and activated in the Shipper Setup of World Ship, we tried it out, thankfully it just worked, the consignment was generated against the company for who the order had been fulfilled.

TNT

We also use the auto import utility with TNT Express Shipper. In this case it is a fixed length text file import, but I applied a similar upgrade for TNT with our technical representative a couple of weeks ago. This results in the account number getting passed and mapped in the TNT software so that again the correct company gets the invoice.

TNT Errors

Another advantage of the new TNT software is that it passes back the consignment number and any errors that have occurred during the import, so it does a full handshake – like UPS have done for a long time. This makes my life easier as I don’t have a job running anymore to pluck the consignment numbers from the TNT SQL database in order to populate the Dynamics GP tracking number tables in Dynamics. As it happens I’ve started using our own consignment numbers now so GP is the source of the consignment number, but having access to errors allows us to correct address records in Dynamics GP that consistently throw exceptions in Express Manager. These exceptions are usually things like town in wrong field or a post code update making a post code invalid that was entered in the past in GP. Mismatches can occur between the versions of post code PAF file on GP and on TNT.

Conclusion

My fulfilment software now passes the account numbers for the carriers through depending on the owner company of the order in GP. This account number is used by TNT or UPS to assign that consignment to the correct company for invoicing, that in turn makes the accounts department happy as the billing gets easier.

Next…

It was also mentioned by TNT that they can now provide electronic invoices, UPS have done for years but this means it is now worth importing the actual cost of carriage back into GP so we can get a better analysis of margin for individual orders.