Every once in a while, I speak with a Dynamics GP customer that complains about their Dynamics GP partner. They aren't available, they are too busy, they aren't responsive, their estimates are outrageous, their consultants aren't very knowledgeable...there are lots of reasons that they may be dissatisfied.
My first question is always: "Have you spoken to your partner to let them know that you are dissatisfied?"
Most of the time, it seems that the GP partner is completely unaware that their client is dissatisfied.
Any GP partner that has been around for a while has received that unexpected e-mail from Microsoft letting them know that their customer has switched partners. Sometimes they understand, and with hindsight can guess why the customer switched partners. But other times it may be completely unexpected, and the partner really doesn't know why the customer switched.
I can understand that it may not be obvious to GP customers to call someone at their partner to complain. In an ideal world, they shouldn't have to because they should be receiving great service. But the reality of consulting is that not all consultants are great, not all consultants know everything about everything, not all GP partners have the ideal number and variety of consultants to handle all customer needs at all times, and not every interaction between a consultant and a customer goes perfectly.
Dynamics GP customers that have worked with their partner for a while should be benefiting from the knowledge that their consultants have gained. The consultant should know their business, business processes, accounting processes, and Dynamics GP configuration and preferences. The relationship with the partner should save them time and expense.
But sometimes the relationship just doesn't work the way the customer would like. Something happens and the customer becomes dissatisfied. Very often, the customer will feel frustrated or upset, but won't speak with the manager or owner at their partner. Like any relationship, there needs to be communication.
Rather than make that communication seem like a burden that the customer must initiate by complaining to their partner, I would recommend that customers simply think of it as demanding good service. If you are served the wrong dish at a restaurant, you probably don't hesitate to return it. If you receive the wrong item or are dissatisfied with an online purchase, you return it. Working with GP partners and consultants is similar--you don't always get what you want, and sometimes you just need to let the partner know. You shouldn't have to get upset with the partner.
Some recommendations in no particular order:
1. Don't be shy. You are the Customer with a capital "C". If you are paying the bills, you shouldn't be reluctant to demand good service. Don't feel bad about asking your partner to resolve an issue to your satisfaction or meet your expectations. Don't be afraid to share your dissatisfaction in a civil manner.
2. Pick up the phone. If a consultant isn't meeting your expectations, let the manager or owner know. At the hourly rates you are paying, you should be getting an experienced, certified, knowledgeable, professional, competent consultant that provides good service. Don't settle for bad or even mediocre. In my experience, most partners aren't very proactive when it comes to getting specific and timely customer feedback, so it is usually up to you, the Customer, to communicate with your partner. Don't wait until the budget is exceeded or the deadlines have past before you let the partner know there is an issue.
3. Know your options and make requests. You are the Customer, not the Victim, so you can make requests and do what it takes to be happy. If a consultant isn't knowledgeable in a particular area, you can ask for someone who is. If the consultant isn't organized or can't communicate well or is unresponsive, you can ask for a different consultant. If the consultant makes obvious mistakes and then bills you to fix them, you can ask for a credit for the specific hours wasted. And if the partner doesn't have better resources and can't resolve issues after you make your requests, then you can find a new partner. Just fill out a single page document and send it to Microsoft and you will be switched. But just be aware that switching partners can be costly. In addition to having to find and interview new partners, you may lose alot of knowledge that your old partner had, and you may have to pay your new partner to come up to speed on your business and GP environment.
4. Take more control. Some GP customers never rely on their partner--they have the resources and developed the skills to be very self sufficient, and only rarely call on their partner for a few items. Other GP customers have a GP partner, but never use them--they prefer to only use independent GP consultants that are experts in certain domains. Maybe they have a GP Manufacturing expert, an Integration developer, and a general support consultant, all independent and living in different states (or countries). And some companies use their partner and independent GP consultants to get the exact mix of resources that they need.
With all of this said, there are also some things to avoid as a GP customer.
1. Be reasonable. Don't demand things for free, don't expect consultants and partners to know everything, don't make up expectations about costs, timelines, or deliverables in a vaccuum.
2. Don't constantly ask for credits. See #1. If you are constantly having problems and you regularly ask for credits, you are treating the symptoms, not the underlying problem. If the problem can't be resolved, you need to find a new partner.
3. It might not be the partner. If you have recurring issues, don't assume that the partner is the problem. Some customers have employees that just can't be satisfied, love to complain, and just aren't happy until they "save money" by fighting over every invoice. If the partner rolls their eyes and groans every time they see your e-mail or get your phone call, they probably aren't going to deliver the best service, especially when they have other clients that are appreciative and truly value their services.
4. Don't keep switching partners. If you have switched partners more than once in the last few years, see #3 above.
Do you have any other suggestions for making a relationship work with a GP partner? Post a comment and let me know.
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
Thursday, May 31, 2012
Tuesday, May 29, 2012
Where are the Dynamics GP eConnect sample projects located?
By Steve Endow
I was recently asked where the Dynamics GP eConnect sample files were located. It has been so long since I looked at them, I didn't even know where to begin to look.
I'll use GP 2010 / eConnect 2010 as the reference for the information below, and eConnect 10 and eConnect 9 should be pretty similar.
First, when you install eConnect, you will want to select the "Help and Samples" feature during the installation. If you have already installed eConnect, you can locate the "eConnect for Microsoft Dynamics GP 2010" program in Control Panel -> Programs and Features and verify that you installed Help and Samples. It is installed by default, so you most likely have the feature already.
Next, locate the 32-bit Program Files eConnect application directory. On my 64-bit Windows Server 2008 R2 machine, the directory was located at:
C:\Program Files (x86)\Microsoft Dynamics\eConnect 11.0\
You should have a subdirectory called "eConnect Samples":
C:\Program Files (x86)\Microsoft Dynamics\eConnect 11.0\eConnect Samples
In that directory, you should see 10 project directories with sample eConnect Visual Studio projects.
The eConnect sample projects are in Visual Studio 2005 format. And although the code appears to have been updated to use the eConnect 2010 "CreateEntity" and "CreateTransactionEntity" methods, the eConnect References appear to be pointing to the eConnect 10 components, so you will need to update the references.
The projects also use the less than ideal method of saving the serialized eConnect XML data out to a file on the file system before reading the file back into memory to send to eConnect.
Although not the only other approach, I have a blog post on a method that is much more elegant, and that I now prefer.
I was recently asked where the Dynamics GP eConnect sample files were located. It has been so long since I looked at them, I didn't even know where to begin to look.
I'll use GP 2010 / eConnect 2010 as the reference for the information below, and eConnect 10 and eConnect 9 should be pretty similar.
First, when you install eConnect, you will want to select the "Help and Samples" feature during the installation. If you have already installed eConnect, you can locate the "eConnect for Microsoft Dynamics GP 2010" program in Control Panel -> Programs and Features and verify that you installed Help and Samples. It is installed by default, so you most likely have the feature already.
Next, locate the 32-bit Program Files eConnect application directory. On my 64-bit Windows Server 2008 R2 machine, the directory was located at:
C:\Program Files (x86)\Microsoft Dynamics\eConnect 11.0\
You should have a subdirectory called "eConnect Samples":
C:\Program Files (x86)\Microsoft Dynamics\eConnect 11.0\eConnect Samples
In that directory, you should see 10 project directories with sample eConnect Visual Studio projects.
The eConnect sample projects are in Visual Studio 2005 format. And although the code appears to have been updated to use the eConnect 2010 "CreateEntity" and "CreateTransactionEntity" methods, the eConnect References appear to be pointing to the eConnect 10 components, so you will need to update the references.
The projects also use the less than ideal method of saving the serialized eConnect XML data out to a file on the file system before reading the file back into memory to send to eConnect.
Although not the only other approach, I have a blog post on a method that is much more elegant, and that I now prefer.
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.
Monday, May 28, 2012
Allocating Payroll in Dynamics GP
Steve has rightly shamed me in posting here on our blog. I could give you all a litany of reasons why I have been so busy lately both personally and professionally, but it would bore you to tears! So I am just going to do what needs to be done, which is actually write a post :)
I have been working on an implementation that just went live two weeks ago, and we are now moving ahead in to phase 2 which is payroll. Exciting stuff, I know. But I had a conversation with the client last week that reminded me some basics when it comes to allocation options for payroll. First, let me give you a background on what I mean by allocations in payroll.
Let's say that I have an administrative employee, who needs to be allocated to other departments. This tends to fall in to two categories in terms of how the calculation needs to work:
When allocating by hours worked, it is a fairly straightforward process. For example, if I needed to allocate an hourly employee to two different departments, I would record the two time entries individually as follows in Payroll Transaction Entry (Transactions-Payroll-Transaction Entry):
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.
I have been working on an implementation that just went live two weeks ago, and we are now moving ahead in to phase 2 which is payroll. Exciting stuff, I know. But I had a conversation with the client last week that reminded me some basics when it comes to allocation options for payroll. First, let me give you a background on what I mean by allocations in payroll.
Let's say that I have an administrative employee, who needs to be allocated to other departments. This tends to fall in to two categories in terms of how the calculation needs to work:
- Allocate by hours worked, which would be the most exact on a payroll by payroll basis, but requires that this information be collected and recorded.
- Allocate based on a fixed percentage/logic, which would generally be less exact but does not require hours to be tracked/entered by department.
When allocating by hours worked, it is a fairly straightforward process. For example, if I needed to allocate an hourly employee to two different departments, I would record the two time entries individually as follows in Payroll Transaction Entry (Transactions-Payroll-Transaction Entry):
By default, both of these transactions would be recorded for Angela's home department, Installation (INST). But if we click the Department lookup, we can select a different department as shown below.
So, now the 30 hours will be recorded for the Sales department. The process is just a bit different for salaried employees. Generally, you don't need to record transactions for salaried employees- only if they are taking vacation, sick, or holiday time. But in order to allocation a portion of their salary to another department, we would enter a transaction as follows:
When you select a Salary pay code for a transaction, the Payroll Salary Adjustment window will open automatically. When allocation, we are interested in the options to Reallocate Hours and Reallocate Dollars. If you select either of these options, you can then enter either a number of hours or a dollar amount to allocate to the department entered on the transaction. And, just like with hourly employees, the department will default to the employee's home department but it can be changed using the Department lookup. Allocations like these can be set up in a recurring batch, for example if a salaried employee's hours are reallocated the same way for every pay period.
Let's say that you want to use the second method above, where the allocation is based on a fixed percentage and not broken out by hours as we just outlined. Allocating by fixed percentages can be handled using Fixed Allocation Accounts in combination with your Payroll Posting Accounts setup. So, first, you would need to set up a Fixed Allocation Account to store the percentages and accounts used in the allocation (Cards-Financial-Fixed Allocation):
The Fixed Allocation Account itself must be a unique account number, and then under Distribution Account you enter the posting accounts and percentages to be used. Once you have the Fixed Allocation Account setup, you would need to use it in your Payroll Posting Accounts Setup (Microsoft Dynamics GP-Tools-Setup-Posting-Payroll Accounts):
So, in the case of the screenshot above, we are allocating Gross Wages. We have specified that for the ADMIN department, any wages that use the SALY pay code will post to our fixed allocation account 000-5109-000. Now, as you can imagine, if you have different allocation breakdowns (which would required different fixed allocation accounts) then you need to consider how you can set up your payroll posting accounts to route the wages to the proper fixed allocation account. For example, you might have differnet percentages based on department or based on pay code or based on position.
Hope this was a helpful reminder of allocation options related to payroll in Dynamics GP. Please share your own clever tips and tricks for allocating!
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.
Friday, May 25, 2012
Problem with Dynamics GP 2010 EFT Payables CCD+ CTX File Format
UPDATE: An anonymous comment was posted below, apparently from someone at Microsoft, explaining that this does appear to be a bug in GP 2010 SP2. As of May 2012 there was no scheduled date for a fix. For those already on GP 2010 SP2 or later, you should be able to use the CCD+ format and uncheck the "Detail Line Addenda" option.
For those who have not yet upgraded to GP 2010 SP2 or later and are on an earlier release of GP 2010, there is a separate bug in the CCD+ format that causes GP to export multiple addenda lines instead of a single line for the CCD+ specification. Since my client is not yet on GP 2010 SP2, this means that they cannot use CCD+, and that we must now use the CCD format. Unless you are paying vendors that can utilize the extra data that the CCD+ or CTX formats provide, CCD should be fine. But if you have vendors that can receive your detail remittance data in a CTX file format, you'll need to wait for a fix (unless you want to manually edit the file, or ask your bank to accept a non-standard file).
I'm guessing this is a pretty obscure feature that relatively few people have used, but I thought I would document it in case some other poor soul experiences the same issue.
I am setting up Dynamics GP 2010 EFT Payables for a client. Since their bank supports sending multiple remittance lines in the ACH file (aka ACH "addenda" records), I thought that we might as well go that route in case any of their vendors can receive the remittance electronically via an ACH download.
And luckily, with GP 2010 SP2, Microsoft has added a feature in the EFT File Format setup that enables GP to export multiple addenda records. This feature is apparently referred to as a "CTX" file format, and was introduced into the ACH file format standard in late 2007.
http://support.microsoft.com/kb/2551488
Unfortunately, from what I can tell, there is a problem with the GP 2010 implementation of the CTX file format.
When you setup the CTX file format to send multiple addenda records, you need to also send the number of addenda records per payment. So if you send a $1,000 payment to a vendor to pay off 10 invoices, you will send an addenda count value of "0010" in your "Detail" record, followed by the 10 addenda records.
Here is some documentation I found on the NACHA CTX file format, shown on page 11.
http://www.regaltek.com/docs/NACHA%20Format.pdf
Note Field 8, "Number of Addenda Records". This field is not required for CCD+, which only supports a single addenda record--but if you use the GP "Detail Line Addenda" option, you move up to the CTX format, which does require this field.
From what I can tell, Dynamics GP EFT does not have a field or feature that allows it to send this addenda count value in the detail record. If you try and add the field, it always sends a value of "0000", as shown below in red:
6221231231231234567890 00000306001EFT 0000TEST EFT VENDOR 011123123120000001
In this example, I used the "Addenda Count" Calculation Type in the EFT File Format setup window, but obviously that doesn't work.
The Addenda Count calculation type is used in the Addenda lines to sequentially number the addenda rows, so my guess is that the Addenda Count value is only active in Addenda lines, and only offers a sequential value, and does not provide a value or addenda count in other line types.
I've looked through and tested several other Calculation Type values, and checked other options, such as Data Fields, but none seem to provide the required addenda count value.
I posted this issue on the Community Forum, but not surprisingly I haven't received any responses yet. The client doesn't want to bother with a support case, so for now I'll be disabling the "Detail Line Addenda" option.
I'm guessing that this is either a bug or a lack of full support for the CTX file format. If anyone has more info, has had a similar experience, or knows of a workaround, please post a comment and let me know.
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
For those who have not yet upgraded to GP 2010 SP2 or later and are on an earlier release of GP 2010, there is a separate bug in the CCD+ format that causes GP to export multiple addenda lines instead of a single line for the CCD+ specification. Since my client is not yet on GP 2010 SP2, this means that they cannot use CCD+, and that we must now use the CCD format. Unless you are paying vendors that can utilize the extra data that the CCD+ or CTX formats provide, CCD should be fine. But if you have vendors that can receive your detail remittance data in a CTX file format, you'll need to wait for a fix (unless you want to manually edit the file, or ask your bank to accept a non-standard file).
I'm guessing this is a pretty obscure feature that relatively few people have used, but I thought I would document it in case some other poor soul experiences the same issue.
I am setting up Dynamics GP 2010 EFT Payables for a client. Since their bank supports sending multiple remittance lines in the ACH file (aka ACH "addenda" records), I thought that we might as well go that route in case any of their vendors can receive the remittance electronically via an ACH download.
And luckily, with GP 2010 SP2, Microsoft has added a feature in the EFT File Format setup that enables GP to export multiple addenda records. This feature is apparently referred to as a "CTX" file format, and was introduced into the ACH file format standard in late 2007.
http://support.microsoft.com/kb/2551488
Unfortunately, from what I can tell, there is a problem with the GP 2010 implementation of the CTX file format.
When you setup the CTX file format to send multiple addenda records, you need to also send the number of addenda records per payment. So if you send a $1,000 payment to a vendor to pay off 10 invoices, you will send an addenda count value of "0010" in your "Detail" record, followed by the 10 addenda records.
Here is some documentation I found on the NACHA CTX file format, shown on page 11.
http://www.regaltek.com/docs/NACHA%20Format.pdf
Note Field 8, "Number of Addenda Records". This field is not required for CCD+, which only supports a single addenda record--but if you use the GP "Detail Line Addenda" option, you move up to the CTX format, which does require this field.
From what I can tell, Dynamics GP EFT does not have a field or feature that allows it to send this addenda count value in the detail record. If you try and add the field, it always sends a value of "0000", as shown below in red:
6221231231231234567890 00000306001EFT 0000TEST EFT VENDOR 011123123120000001
In this example, I used the "Addenda Count" Calculation Type in the EFT File Format setup window, but obviously that doesn't work.
The Addenda Count calculation type is used in the Addenda lines to sequentially number the addenda rows, so my guess is that the Addenda Count value is only active in Addenda lines, and only offers a sequential value, and does not provide a value or addenda count in other line types.
I've looked through and tested several other Calculation Type values, and checked other options, such as Data Fields, but none seem to provide the required addenda count value.
I posted this issue on the Community Forum, but not surprisingly I haven't received any responses yet. The client doesn't want to bother with a support case, so for now I'll be disabling the "Detail Line Addenda" option.
I'm guessing that this is either a bug or a lack of full support for the CTX file format. If anyone has more info, has had a similar experience, or knows of a workaround, please post a comment and let me know.
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
Monday, May 21, 2012
DEX.DIC version 11.00.0349 is not compatible with executable version 11.00.0354
I've been trying to figure out a problem with an EFT file format in Dynamics GP 2010 SP2, which I think might be a bug. To see if it might have been fixed in a Hotfix (wishful thinking, I know), I downloaded the March 2012 Hotfix 11.00.1935.
The update launched and started to run, but about half way through, this error appears:
Lovely.
This is a rather vanilla GP 2010 SP2 install on a test server. The Dynamics.exe was version 11.00.0354, so it would appear that the DEX.DIC that the hotfix is trying to install is 11.00.0349?
When I click OK, the same message popped up two more times. After that, the update appears to complete and asks for a machine reboot. I complied and rebooted the server.
Never one to be afraid of an error message that is likely catastrophic, I launch GP Utilities after the reboot, which showed version 11.00.1752 (not promising), and run the update process.
No joy. GP utilities did appear to perform some tasks, but then hangs at the Update System Tables step. An Update Progress dialog appears, but let's just say that it didn't make much progress.
I launched SQL Server Profiler to see if there was any database activity, but there was none.
I then killed the process, rebooted, and decided to run the Hotfix install again. This second time it completed without error, and launched a "Dexerity Shared Components 11.0 (64-bit)" installation, which also completed successfully.
Just to be safe, I rebooted once more and then ran GP Utilities again.
It politely acknowledged that the previous upgrade attempt failed.
And then it showed a different dialog than the "Update Progress" dialog I saw the first time, indicating that it was waiting for system tables to update.
This time, SQL Profiler showed a lot of activity, so I let it run. And run. And run.
After SQL Profiler collected over 112,000 rows of SQL Activity, I became suspicious. Just glancing at the SQL flying by, I noticed that the statements appeared to be repetitive. I paused Profiler and reviewed the SQL. Sure enough, it was the same SQL statements running over and over. The statements were convoluted select statements that would never return anything.
Despite several additional attempts, I couldn't get past this eternal Groundhog Day of SQL statements.
Having wasted enough time by this point, I threw in the towel and completely uninstalled GP 2010 and reinstalled from scratch.
Next time, I'll try and remember to make sure to backup my GP directory and databases before the install so I can completely revert.
Not a big deal for me, since it's just my development server, but I don't envy the person who has his happen in their production environment.
UPDATE: I completely removed GP 2010 then reinstalled from scratch. Before launching GP Utilities, I installed the March 2012 Hotfix and it ran without error. GP Utilities launched, this time showing version 11.00.1935. So it seems that during my original attempt to install the Hotfix, it failed to complete its upgrade of GP files, despite running it twice.
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
The update launched and started to run, but about half way through, this error appears:
DEX.DIC version 11.00.0349.000 is not compatible with executable version 11.00.0354.000.
This is a rather vanilla GP 2010 SP2 install on a test server. The Dynamics.exe was version 11.00.0354, so it would appear that the DEX.DIC that the hotfix is trying to install is 11.00.0349?
When I click OK, the same message popped up two more times. After that, the update appears to complete and asks for a machine reboot. I complied and rebooted the server.
Never one to be afraid of an error message that is likely catastrophic, I launch GP Utilities after the reboot, which showed version 11.00.1752 (not promising), and run the update process.
No joy. GP utilities did appear to perform some tasks, but then hangs at the Update System Tables step. An Update Progress dialog appears, but let's just say that it didn't make much progress.
I then killed the process, rebooted, and decided to run the Hotfix install again. This second time it completed without error, and launched a "Dexerity Shared Components 11.0 (64-bit)" installation, which also completed successfully.
Just to be safe, I rebooted once more and then ran GP Utilities again.
It politely acknowledged that the previous upgrade attempt failed.
And then it showed a different dialog than the "Update Progress" dialog I saw the first time, indicating that it was waiting for system tables to update.
After SQL Profiler collected over 112,000 rows of SQL Activity, I became suspicious. Just glancing at the SQL flying by, I noticed that the statements appeared to be repetitive. I paused Profiler and reviewed the SQL. Sure enough, it was the same SQL statements running over and over. The statements were convoluted select statements that would never return anything.
Despite several additional attempts, I couldn't get past this eternal Groundhog Day of SQL statements.
Having wasted enough time by this point, I threw in the towel and completely uninstalled GP 2010 and reinstalled from scratch.
Next time, I'll try and remember to make sure to backup my GP directory and databases before the install so I can completely revert.
Not a big deal for me, since it's just my development server, but I don't envy the person who has his happen in their production environment.
UPDATE: I completely removed GP 2010 then reinstalled from scratch. Before launching GP Utilities, I installed the March 2012 Hotfix and it ran without error. GP Utilities launched, this time showing version 11.00.1935. So it seems that during my original attempt to install the Hotfix, it failed to complete its upgrade of GP files, despite running it twice.
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
Wednesday, May 16, 2012
Error e-mailing PDF reports with GP 2010 and Office 2010
I was recently trying to setup and test e-mailing vendor remittance documents for a client that is setting up Electronic Funds Transfer for Payables.
When I tested the process on one of my servers, I received the following error:
You must have the Microsoft Save as PDF or XPS Add-in for 2007 Microsoft Office installed to send documents
I tried e-mailing other documents as PDF, such as a sales invoice, but received the same error throughout GP.
Since I have Office 2010 installed, clearly the message about Office 2007 is erroneous, but it obviously indicates that GP is unable to e-mail the reports as PDFs. And I confirmed that I did have the 32-bit versions of Office 2010 installed, as the 64-bit version is not compatible with GP 2010 R2 for e-mailing reports.
I read a forum post indicating that at least a handful of other people have experienced this error, but there didn't appear to be any consensus on a cause or resolution.
I was able to e-mail the reports as DOCX files, so the e-mail process worked, but the conversion to PDF wasn't working.
So I installed 32-bit Office 2010 with default settings on a second server with GP 2010 R2 and tested e-mailing reports as PDFs. It worked fine on the second server, no errors. Hmmm. So my issue was clearly server-specific.
I began to think that my Office 2010 installation was probably the issue. I have a habit of trying to remove as much junk as possible from the Office installation--it installs hundreds of "features" that I never use and consider useless. But perhaps I was a bit too aggressive and excluded a component that GP requires to do it's magic converting Word Templates to PDF for e-mailing.
After two tries adding back components to my Office 2010 installation, I found the item that was causing the problem.
In the Office 2010 Installation Options window, under Microsoft Word, there is an item called ".NET Programmability Support".
I almost never use .NET to program Word or interact with Word, so I had excluded that item from my Office installation.
I set the feature to be installed, completed the Office setup, and then launched GP 2010 R2. Sure enough, I was able to e-mail PDF attachments from within GP. Worked like a charm.
Presumably there are relatively few people that are as picky as me when it comes to installing useless Office features, so this is probably a rare cause of this particular error. But just a note that the Word 2010 .NET Programmability Support feature is required in order for GP 2010 to do it's PDF e-mailing magic.
There are other causes for this error, such as the obscure case that Dave Dusek explains in this blog post, so the one I experienced is just one possible explanation.
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
When I tested the process on one of my servers, I received the following error:
You must have the Microsoft Save as PDF or XPS Add-in for 2007 Microsoft Office installed to send documents
I tried e-mailing other documents as PDF, such as a sales invoice, but received the same error throughout GP.
Since I have Office 2010 installed, clearly the message about Office 2007 is erroneous, but it obviously indicates that GP is unable to e-mail the reports as PDFs. And I confirmed that I did have the 32-bit versions of Office 2010 installed, as the 64-bit version is not compatible with GP 2010 R2 for e-mailing reports.
I read a forum post indicating that at least a handful of other people have experienced this error, but there didn't appear to be any consensus on a cause or resolution.
I was able to e-mail the reports as DOCX files, so the e-mail process worked, but the conversion to PDF wasn't working.
So I installed 32-bit Office 2010 with default settings on a second server with GP 2010 R2 and tested e-mailing reports as PDFs. It worked fine on the second server, no errors. Hmmm. So my issue was clearly server-specific.
I began to think that my Office 2010 installation was probably the issue. I have a habit of trying to remove as much junk as possible from the Office installation--it installs hundreds of "features" that I never use and consider useless. But perhaps I was a bit too aggressive and excluded a component that GP requires to do it's magic converting Word Templates to PDF for e-mailing.
After two tries adding back components to my Office 2010 installation, I found the item that was causing the problem.
In the Office 2010 Installation Options window, under Microsoft Word, there is an item called ".NET Programmability Support".
I almost never use .NET to program Word or interact with Word, so I had excluded that item from my Office installation.
I set the feature to be installed, completed the Office setup, and then launched GP 2010 R2. Sure enough, I was able to e-mail PDF attachments from within GP. Worked like a charm.
Presumably there are relatively few people that are as picky as me when it comes to installing useless Office features, so this is probably a rare cause of this particular error. But just a note that the Word 2010 .NET Programmability Support feature is required in order for GP 2010 to do it's PDF e-mailing magic.
There are other causes for this error, such as the obscure case that Dave Dusek explains in this blog post, so the one I experienced is just one possible explanation.
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
Tuesday, May 15, 2012
Decisions Spring 2012 Virtual Conference: Dynamics GP Day June 19th
Make sure to register for the Decisions Spring 2012 virtual conference!
Dynamics GP day is on Tuesday, June 19th. Registration is free!
The virtual conference is a great way to learn more about Dynamics GP from top speakers and luminaries, learn about ISV solutions that integrate with Dynamics GP, and have a chance to chat with other Dynamics GP customers, consultants, and community members.
Here are just a few of the presentations:
Erroll Schoenfish, Director of Product Management from Microsoft, will be speaking about the upcoming Dynamics GP 2013 product release.
Jivtesh Singh will be sharing some insight about the new Dynamics GP Web Client.
Mariano Gomez will be explaining how you can get to know your MVPs better.
Mark Polino will be offering an introduction to the topic of Corporate Performance Management, having already published "The Stakeout", a guide to virtual events.
Amber Bell will enlighten you on how to work smarter with SmartLists and SmartList Builder.
Chetna Bawa will be covering how to import data into Dynamics GP (a topic near and dear to me!).
My blog-mate Christina Phillips will be sharing her extensive knowledge on how to use Word Templates and e-mailing in Dynamics GP.
Last, I will humbly present how to unleash Dynamics GP by taking advantage of additional features, modules, ISV solutions, development tools, and integration options to get more value out of your Dynamics GP solution.
The list of speakers is long, and distinguished, so make sure to block out a few hours on June 19th to invest in some education to learn more about your absolutely most favorite ERP application in the whole wide world.
Register now!
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
Dynamics GP day is on Tuesday, June 19th. Registration is free!
The virtual conference is a great way to learn more about Dynamics GP from top speakers and luminaries, learn about ISV solutions that integrate with Dynamics GP, and have a chance to chat with other Dynamics GP customers, consultants, and community members.
Here are just a few of the presentations:
Erroll Schoenfish, Director of Product Management from Microsoft, will be speaking about the upcoming Dynamics GP 2013 product release.
Jivtesh Singh will be sharing some insight about the new Dynamics GP Web Client.
Mariano Gomez will be explaining how you can get to know your MVPs better.
Mark Polino will be offering an introduction to the topic of Corporate Performance Management, having already published "The Stakeout", a guide to virtual events.
Amber Bell will enlighten you on how to work smarter with SmartLists and SmartList Builder.
Chetna Bawa will be covering how to import data into Dynamics GP (a topic near and dear to me!).
My blog-mate Christina Phillips will be sharing her extensive knowledge on how to use Word Templates and e-mailing in Dynamics GP.
Last, I will humbly present how to unleash Dynamics GP by taking advantage of additional features, modules, ISV solutions, development tools, and integration options to get more value out of your Dynamics GP solution.
The list of speakers is long, and distinguished, so make sure to block out a few hours on June 19th to invest in some education to learn more about your absolutely most favorite ERP application in the whole wide world.
Register now!
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
GP 2010 Web Services error: There was no endpoint listening at at http://server:48620/Dynamics/GPService
A partner recently asked me to help them troubleshoot a Dynamics GP 2010 Web Services error that they were receiving:
There was no endpoint listening at http://server:48620/Dynamics/GPService that could accept the message.
I've previously written about an eConnect 2010 error message that looks very similar. In the case of eConnect 2010, you simply make sure the eConnect windows service is started.
But in this case, we checked the Windows services, and both eConnect 2010 Integration Service and the Microsoft Dynamics GP Service Host were both running. There were no errors in the Event Viewer or the Dynamics GP Web Services Exceptions Console.
The partner had contacted GP support, and was asked to open the Dynamics Security Console to perform a test. They recommended trying to add a Customer Entity ID Assignment, to see if customer IDs were listed in the window. But when the partner tried to add the Entity ID assignment, the Company drop down list was empty. This was the first clue.
This is what the Entity ID Assignment window should look like:
Once you select a Windows user, Entity Type, and Company, a list of IDs should appear. But they couldn't even select a Company.
To try and diagnose the issue further, I installed GP 2010 Web Services on one of my servers and whipped up a test application that would use GP Web Services to retrieve customers, vendors, items, and accounts. We could then use this app on different machines to see if it was a network issue or a problem with Web Services.
The partner tried my test application, and it didn't even work on the GP server where Web Services was installed, so that ruled out a network issue.
I then tried the Entity ID Assignment test on my server, and it worked fine. The Fabrikam company was listed and I was able to see a list of customers. (as shown above)
So this told us that the problem was likely with the installation or configuration of Web Services.
I then asked the partner to try launching the GP Web Services Configuration Wizard to see if web services had been configured for the Fabrikam company. When they launched the Configuration Wizard, no companies were listed. They were unable to even proceed with the configuration or repair.
The window should list a company like this:
That pretty much told us that there was something wrong with the Web Services installation, and I recommended that they try completely uninstalling and reinstalling, making sure to follow the install guide step by step.
Once Web Services was reinstalled, things worked properly and their Web Services integration started working.
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
There was no endpoint listening at http://server:48620/Dynamics/GPService that could accept the message.
I've previously written about an eConnect 2010 error message that looks very similar. In the case of eConnect 2010, you simply make sure the eConnect windows service is started.
But in this case, we checked the Windows services, and both eConnect 2010 Integration Service and the Microsoft Dynamics GP Service Host were both running. There were no errors in the Event Viewer or the Dynamics GP Web Services Exceptions Console.
The partner had contacted GP support, and was asked to open the Dynamics Security Console to perform a test. They recommended trying to add a Customer Entity ID Assignment, to see if customer IDs were listed in the window. But when the partner tried to add the Entity ID assignment, the Company drop down list was empty. This was the first clue.
This is what the Entity ID Assignment window should look like:
Once you select a Windows user, Entity Type, and Company, a list of IDs should appear. But they couldn't even select a Company.
To try and diagnose the issue further, I installed GP 2010 Web Services on one of my servers and whipped up a test application that would use GP Web Services to retrieve customers, vendors, items, and accounts. We could then use this app on different machines to see if it was a network issue or a problem with Web Services.
I then tried the Entity ID Assignment test on my server, and it worked fine. The Fabrikam company was listed and I was able to see a list of customers. (as shown above)
So this told us that the problem was likely with the installation or configuration of Web Services.
I then asked the partner to try launching the GP Web Services Configuration Wizard to see if web services had been configured for the Fabrikam company. When they launched the Configuration Wizard, no companies were listed. They were unable to even proceed with the configuration or repair.
The window should list a company like this:
That pretty much told us that there was something wrong with the Web Services installation, and I recommended that they try completely uninstalling and reinstalling, making sure to follow the install guide step by step.
Once Web Services was reinstalled, things worked properly and their Web Services integration started working.
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
Thursday, May 10, 2012
Why don't you own Rockton SmartFill?
One of the most useful, most valuable, and most obvious ISV solutions for Dynamics GP that I have used is Rockton SmartFill. If you aren't familiar with SmartFill, you should be. If you aren't using SmartFill with your Dynamics GP system, you should be. There are probably some companies with only 3 users, a handful of customers, vendors, inventory items, and GL accounts where the accounting staff have memorized all of the IDs and account numbers and never use lookups--but for the rest of you, who are constantly using the horrible Dynamics GP lookup windows, you, yes you, should "invest" in Rockton SmartFill.
For example, instead of guessing a customer ID or resorting to the Customer lookup window, just type part of the customer's name and tab off of the Customer ID field. A search result dialog appears listing your options. This functionality is applied to nearly all of the Dynamics GP 'lookup' fields, and can be adjusted to suit your needs.
Despite my belief that SmartFill is a no-brainer purchase for nearly every GP customer, I have only had ONE client that purchased it. Since I first used it, I have pitched SmartFill to nearly every Dynamics GP customer that I have worked with, and not a single customer purchased it. This baffles me. I'm obviously not an award winning salesman, but I would have thought that customers would see how it works and instantly want to purchase it. But it just hasn't happened. And I don't understand why.
At $150 per concurrent user, SmartFill seems like a bargain to me. If a company pays $25,000 for 10 Dynamics GP Business Essentials users, or $40,000 for 10 Advanced Management users, I'm thinking that $1,500 for SmartFill is not a huge additional investment, especially considering the efficiency it provides. $150 per user to increase data entry speed and accuracy? To make the entire Dynamics GP system much more usable? To avoid those crude Dynamics GP lookup windows??? It seems like an obvious choice to me.
So why don't you use SmartFill? What's stopping you?
(I have no affiliation with Rockton and don't get a penny for recommending their products. I just think it's a great product, and am puzzled why more people don't use it...)
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
For example, instead of guessing a customer ID or resorting to the Customer lookup window, just type part of the customer's name and tab off of the Customer ID field. A search result dialog appears listing your options. This functionality is applied to nearly all of the Dynamics GP 'lookup' fields, and can be adjusted to suit your needs.
Despite my belief that SmartFill is a no-brainer purchase for nearly every GP customer, I have only had ONE client that purchased it. Since I first used it, I have pitched SmartFill to nearly every Dynamics GP customer that I have worked with, and not a single customer purchased it. This baffles me. I'm obviously not an award winning salesman, but I would have thought that customers would see how it works and instantly want to purchase it. But it just hasn't happened. And I don't understand why.
At $150 per concurrent user, SmartFill seems like a bargain to me. If a company pays $25,000 for 10 Dynamics GP Business Essentials users, or $40,000 for 10 Advanced Management users, I'm thinking that $1,500 for SmartFill is not a huge additional investment, especially considering the efficiency it provides. $150 per user to increase data entry speed and accuracy? To make the entire Dynamics GP system much more usable? To avoid those crude Dynamics GP lookup windows??? It seems like an obvious choice to me.
So why don't you use SmartFill? What's stopping you?
(I have no affiliation with Rockton and don't get a penny for recommending their products. I just think it's a great product, and am puzzled why more people don't use it...)
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
Wednesday, May 9, 2012
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
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
Friday, May 4, 2012
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.
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.
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.
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.