CBM – Checkbook [checkbook id] is already in user by user [username].


I often come across this request from GP Users:

This happens when the User try to reconcile from CBM Reconcile. And once he/she selects the Checkbook which needs to be reconciled.

After some SQL Profiling & Dex Script Log, I found the following:

Cause:

The table CB100006 contains the User Checkbook Activity records, as and when a User reconciles a Checkbook. This table for some reason is not cleared properly. Sometimes:

1. If you open the form, enter the Checkbook ID and just close it without any activity, this record is not cleared.

2. If you open the form, enter the Checkbook ID and just close GP directly without any activity, this record is stuck.

The above scenarios are faced by me and have not heard of this from any other consultants, so the above need not be recreated consistently.

Resolution:

I. Consultants must open SQL Management Studio, log on to the Data Server and connect to relevant company DB.

II. Run the following queries against DYNAMICS and the respective companies:

/*
   This below queries will delete all stranded and unwanted SQL Sessions.
*/
DELETE TEMPDB..DEX_LOCK WHERE SESSION_ID NOT IN (SELECT SQLSESID FROM DYNAMICS..ACTIVITY)

DELETE TEMPDB..DEX_SESSION WHERE SESSION_ID NOT IN (SELECT SQLSESID FROM DYNAMICS..ACTIVITY)

/*
   The below queries will ensure that the respective user, against whom the error message was thrown, would be cleared from GP Application Session(s).
*/
SELECT * FROM DYNAMICS..ACTIVITY WHERE USERID = ‘[username shown in the CBM error message]’

–Ask that user to log off, if this user has logged on for the day.

III. Run the below query to clear the CBM Checkbook Lock:

DELETE CB100006 WHERE USERID = ‘[username shown in the CBM error message]’

DELETE CBEU1020 WHERE CHEKBKID = ‘[stuck checkbook ID]’ AND USERID = ‘[username shown in the CBM error message]’

That’s it. We are good to go with our Checkbook Reconciliation in CBM.

NOTE: I will be posing another article on CBM Payments Batch Lock Error (which is identical to this error message).

VAIDY

AD LDS & GP Web Service on Windows Server 2008 64 BIT- Workaround


Blown away by this issue and am feeling great to cross a mysterious hurdle.

I was trying to install GP Web Services 10.0 SP4 Hot Fix NOV2009 on the following environment:

1. Windows Server 2008 R2 64 Bit
2. GP 10.0 SP4
3. CRM 4.0 Rollup 9
4. SQL Server 2008 SP1 64 Bit

One of the pre-requisite for Web Services is AD LDS (Active Directory Lightweight Directory Services). This needs to be installed on Windows Server 2008 and no configuration required post installation. GP Web Services will take care of creating an Instance on AD LDS and use it for it’s Data Storage on this AD LDS instance.

I crossed all those steps and started installing GP Web Services and got this message without any delay after double clicking the installer:

The Active Directory Lightweight Directory Services role must be installed on the computer before installing the Microsoft Dynamics GP Web Service.

Nothing other than the above message and I was quite blown away by it’s vagueness. After much exploration, I got the following link from Sivakumar:

Description of the 64-bit operating systems that are supported together with Microsoft Dynamics GP

In that article there is a section called Web Services Runtime Workaround under which there is a subsection called Windows Server 2008 x64 or x86 and Microsoft Dynamics GP 10.0 only, which explains the workaround.

To Summarize the Workaround: With Windows Server 2008 R2 64 Bit, the GP Web Services installation does not identify the AD LDS being installed. It requires a Registry Entry called ADAM_Shared with a registry value, that needs to be created under HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion.

We must be carefully following the steps to avoid any consequences.

For those who do not have access to CustomerSource / PartnerSource and are struggling with this issue, comment on this article or email me to my ID: vaidy.dyngp@gmail.com.

Thanks to Sivakumar & Prem (Elcome’s Sys Admin), who were instrumental in sending this link to me on time and clearly saved my day.

VAIDY

Setting up SSRS in Dynamics GP – Mariano’s Input saved my day


I installed Dynamics GP 10, a fresh install to make sure that I properly install SSRS Add-On and configure it to GP 10.0.

Everything went on well and I started configuring SSRS Paths in Dynamics GP Reporting Tools Setup window.

I entered the path and I received a message “The Report server URL entered is not valid.”. No clue, whatsoever.

I surfed and here I found Mariano’s input to one of the users.

If you are busy enough to not going to that link and read, here is what Mariano had to say:

If you are on SQL Server 2005, the URL should be http://ServerName:PortNumber/reportserver/reportservice.asmx.
However, if your server happens to be a SQL Server 2008 server, the URL should be http://ServerName:PortNumber/reportserver/reportservice2005.asmx.

Thanks Mariano for this input and I am delighted to have succeeded in my task. Though this is for my own R&D, this has kick started a really interesting and sincere learning process.

VAIDY

GP Login with Active Directory – Is it really required?


Customers & Most of the Consultants vote YES. But some still believe that it’s OK to have separate Login Credential for GP.

I also wonder whether we really require Active Directory Integrated Login for GP. What’s so bugging if we have a separate login?

Pour your ideas and thoughts in here.

VAIDY

Integrating CRM with GP – Mariano’s Guidance


It may be coincidental, but I am of-late reading lots of CRM to GP Integration articles.

This one is another gem from Mariano: Integrating Microsoft Dynamics CRM with Microsoft Dynamics GP in 72 hours…and 5 “Easy” Steps.

May sound like simple things, but very critical things.

MUST READ.

VAIDY

WIN2008, SQL2008 & GP10 – Issue & Resolution


This one may or may not have caught the attention of Consultants. So here you have it.

I was working on a GP 10.0 SP4 installation on the following environment:

1. Windows Server 2008 Standard
2. SQL Server 2008
3. GP 10.0 SP4
4. 64 Bit Environment

I installed SQL Server 2008 first and then installed GP 10.0. When I launched my GP Utilities, the ODBC Data Source to SQL Server was not listed at all. I must admit that I did not search any forums or KB to find out the reason and solution.

But I found this: SQL Server 2008 on Windows Server 2008 R2 must be applied with SP1 mandatorily. This was the reason my ODBC DSN did not get listed in my GP Utilities. I applied SQL2008 SP1 and it worked.

VAIDY