Why consultants shouldn't post Dynamics GP batches on a client's system

I just finished preparing a batch of payables credit memos for a client to adjust some imported transactions that had incorrect freight and misc charge amounts.  After reconciling the data and confirming everything looked good, I let the client know that the batch was ready for them to post.

I'm pretty careful not to post transactions or batches in clients' production environments because of a fun experience I had with a client many years ago.

The client was a $750MM company using Dynamics GP, and they had so much going on that they usually had 1 or 2 GP consultants on site on a regular basis.  We would work with them on everything from AP processing to GL reconciliations, financials, integrations, and audit support.

At one point, I worked with the accounting manager to perform some type of reconciliation that resulted in an adjustment, and I prepared an adjusting batch with the accounting manager.  While sitting together at a GP workstation, she reviewed the batch and agreed that it should be posted, and "we" posted it.

I don't remember who technically clicked the Post button, but that workstation was using my GP login at the time the batch was posted.

Fast forward several months, and the company is doing a financial audit.  Auditors have a surprising ability to find details in accounting data that constantly surprise me, and of course, they found that my GP login posted some GL transactions.

Unfortunately, I wasn't at the client site at the time, so alarms went off, the auditors apparently got a bit too excited, and they then made the client freak out.  I get a call from the client suspiciously asking me if I had been posting transactions in THEIR system.  Despite working with the client for years, spending days and late nights helping them, it apparently crossed their mind that I would tamper with their data.  As if I don't have better things to do...

Of course I had no recollection of the specific transactions or batch, so I had to first calm everyone down, and then had to review the data with 3 people looking over my shoulders (literally) to see why I would have posted transactions.

After reviewing the batch and finding some notes on the adjustment, I was finally able to remind the accounting manager what the batch was for, and remind her of the meeting that we had where she and I reviewed and posted the batch together.

"Oh, yeah, I remember that."

The auditors put away their attack dogs and everyone calmed down.

But I definitely learned my lesson.  No more posting batches--at least not with my login!

Batch or transaction level notes are probably also a good idea, especially for adjustments, to document who, what, and why for the transactions.


Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com

Promising Performance Bumps in MR 2012

I know that I have been pretty vocal in my overall love for Management Reporter.  Not that FRx was horrible, its just that Management Reporter is moving in such a great direction.  So it has always been a bit frustrating to me to get bogged down in the performance issues with MR-- just because it takes away from all the great aspects of it. 

So I was excited when we had an opportunity to put MR 2012 in to a test environment.  Now, in this case, we were testing with AX (which MR now has a completely different underlying data mart model), but the performance increase was nothing short of amazing.  I am talking about cutting report processing time by over 99%.  Wow.

Now, I don't expect that same level of improvement when it comes to GP (but, then again, GP did not seem to exhibit the same extreme performance issues as AX-- which may be not only due to the product but also due to the client base/size for each), but it does get me excited to get MR 2012 in to play (not to mention the missing account detection functionality that comes with it).

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.

Why Can't I Void a Payroll Check/Direct Deposit?

I had a client ask me a pretty basic question the other day, and it brought me back to one of my favorite KnowledgeBase articles of all time, support.microsoft.com/kb/864992 which is "Void Check Not Working in Payroll".  The article talks through some of the most common reasons that a check is not available for voiding in Transactions-Payroll-Void Checks.



In this particular case, Step 5 in the article was the exact cause...

5. View the CM20200 table in Query Analyzer

SELECT * FROM CM20200 WHERE SRCDOCNUM ='XXXX'
SRCDOCNUM is the check number used in payroll. For the check you are trying to void, the below columns need to have this type of status for the check to appear in the payroll void window. For example, if the RECONUM column is 1.00000, then it will not appear in the void window.
RECONUM = 0
Recond = 0
VOIDED =0 

The transaction was a direct deposit, and it had been reconciled (the client reconciles daily) when it was initially pulled from the bank but then it bounced and was later placed back in to their account.  A simple fix in the future, they plan to adjust the time at which they do the bank reconcilation on direct deposit days to catch the bounces after (not before) they happen.  And to correct this case, they can enter a negative manual check (Transactions-Payroll-Manual Checks) to adjust out the check before reprocessing the payroll for the employee with a live check.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.

My favorite Dynamics GP inventory item for testing

If you have done Dynamics GP demos and had to create a SOP, POP, or Inventory transaction, you've had to choose at least one inventory item to test with.  After doing this enough times, you have probably found an item or two that works.  Preferably one that has quantity on hand, that is assigned to the default warehouse, that is assigned to the vendor, and especially one that isn't serialized.

For years I used to rely on the old standby, 100XLG, our favorite "Green Phone".  It was always at the top of the list, usually had quantity on hand, and was reasonably priced.

But after poking around for additional items to test with, I discovered my new favorite:  FTRUB

Although the description claims they are Rubber Feet, I just love the Item Number, "foot rub". 

Well, yes, it's ERP-geeky, but I thought it was pretty funny. 

FTRUB is now my go-to inventory item for testing.  Post an Inventory Adjustment for 1,000 of those gems, assign it to vendor ACETRAVE0001, and you are all set.


Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com

Clearing remembered / default login for SQL Server Management Studio

By Steve Endow

Occasionally I have to test different SQL Server logins with varying permissions to troubleshoot random GP or integration errors.  Sometimes I test those logins by launching SQL Server Management studio and logging in to SQL to confirm they work and behave as expected.

Well, if you have ever tried this, you know that Management Studio suddenly falls in love with the last login that you used and will always display it as the default Login.

So, after I tested with a login of "testuser", every time I launched SQL Management Studio, I was prompted to login using "testuser", and had to always switch to the 'sa' login on my dev machine.  Seems trivial, but it's incredibly annoying, especially when you are just using to pressing enter to login as 'sa' with saved password.

I tried searching for this issue, but didn't get any relevant results.

Thanks to some help from a fellow expert on Experts Exchange, I was pointed to this Stack Overflow thread that explains how to delete the "remembered" logins for SQL Server Management Studio:

SQL Server Management Studio 17.x delete the file 

C:\Users\%username%\AppData\Roaming\Microsoft\SQL Server Management Studio\14.0\SqlStudio.bin

SQL Server Management Studio 2014 delete the file 

C:\Users\%username%\AppData\Roaming\Microsoft\SQL Server Management Studio\12.0\SqlStudio.bin

SQL Server Management Studio 2012 delete the file 

C:\Users\%username%\AppData\Roaming\Microsoft\Microsoft SQL Server Management Studio\11.0\SqlStudio.bin

SQL Server Management Studio 2008 delete the file

C:\Users\%username%\AppData\Roaming\Microsoft\Microsoft SQL Server\100\Tools\Shell\SqlStudio.bin

SQL Server Management Studio 2005 delete the file – same as above answer but the Vista path.

C:\Users\%username%\AppData\Roaming \Microsoft\Microsoft SQL Server\90\Tools\Shell\mru.dat

Deleting the SqlStudio.bin file worked like a charm, and my 'testuser' is now nowhere to be found.

Just be aware that deleting the file will clear ALL saved server connections, logins, and saved passwords.

Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics GP Certified IT Professional in Los Angeles.  He is the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter

http://www.precipioservices.com

Priorities and Modern Worklife

As a mom of one, and pregnant with my second, this really struck a cord with me.  I don't post often on  here on "soft" topics, but I think this is an important one-- particularly for those of us in the consulting world :)

http://www.cnn.com/2012/04/16/opinion/stone-leave-work-day/index.html?hpt=hp_c1

Resolution for eConnect 2010 Error: The Transaction Has Aborted

Back in September 2011 I wrote about an error I was receiving with a few eConnect 2010 integrations.  In apparent random fashion, the integration would throw the following eConnect exception:

     The transaction has aborted

I researched every aspect of the error that I could think of, and tried every workaround I could imagine, but the error would still occur intermittently with two integrations.  Strangely, the error did not occur with 10 other eConnect integrations running on the same server.

I created a GP support case and worked with Aaron at MS Support over several months trying to figure out the cause and possible ways of troubleshooting the problem.  A few weeks ago, Aaron contacted me to let me know that another customer was getting the same eConnect error, and that they seem to have found the cause.

That customer was calling the eConnect GetNextSopNumber class, and in the process, was also using the Dispose method when using that class.  GP support was able to reproduce the issue with those two elements, apparently triggered by the Dispose method, and they have documented it as a bug.

My two integrations that were getting the error don't use GetNextSopNumber, so I was initially concerned that the other customer's solution wouldn't apply to me.  And as a general rule, I never use Dispose, so I was further concerned that I might be dealing with a different cause for the error.

I found my source code and realized that the two integrations getting the error were older projects that were written in VB, which I stopped using in 2010 after I switched to C#.  I then searched the project for "Dispose", and to my surprise, I was calling the method after submitting data to eConnect.

            returnValue = eConCall.CreateTransactionEntity(gpConnString, transactionXML)
            eConCall.Dispose()

After each call to CreateTransactionEntity and CreateEntity, the Dispose method was being called.  I obviously copied that line from somewhere / someone, since I can't imagine that I would have added the call on my own and have never used it in any of my C# integrations since.

So I went ahead and commented out the Dispose method and deployed the new integrations on the client's server.

It has been about two weeks since I made that change and we haven't had a transaction aborted error since.  We're still monitoring the logs to confirm that the issue is fully resolved, but it's looking good so far.

So, it seems that calling Dispose with any eConnect 2010 class can trigger the error, and simply removing the Dispose call should resolve the issue.

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com