My blog has moved! Please visit the new blog at: https://blog.steveendow.com/
I will no longer be posting to Dynamics GP Land, and all new posts will be at https://blog.steveendow.com
Thanks!
Today I was going to work on a SQL Server Reporting Services project, so I logged on to a GP server with SQL Server 2008 R2 and launched Reporting Services Configuration Manager to see if SSRS was configured.
When I tried to connect to the Reporting Services server, I received the very informative error:
"Invalid class"
After some Googling, I decided to check the status of the SSRS Service. The service was not running.
Starting the SSRS service resolved the issue and the useless error message went away!
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.
Today I fielded an interesting question on Experts Exchange regarding a random Dynamics GP window that was opening when a user logged into GP 2010.
It started out as an error message when the user logged in, saying "You don't have security privileges to open this window." Most of us are familiar with this message.
So the consultant solved that problem with David Musgrave's instructions and the Support Debugging Tool. In the process, he discovered that the window that was causing the error was the Report Schedule window. The what? I haven't had a client that used the GP Report Scheduler, so I had to dig out the documentation just to find the window.
So now that the permissions were fixed, the Report Schedule window would open automatically every time the user logged in. This is pretty odd, since the user doesn't use the Report Schedule window, and never had permissions to open it. And the fact that it was opening automatically was pretty strange as well.
So we both reviewed the documentation, but didn't see any option that would cause the window to open automatically.
The only other thing I could think of was that maybe a window shortcut had been placed in the user's Startup folder. But oddly, no shortcuts were displayed in the user's Startup folder in GP.
The consultant then had a pretty good idea--he traced the location of the user shortcuts to the DYNAMICS..SY01990 table. He then queried that table for the specific user, and found that sure enough, there was a record for the Report Schedule window for that user.
He deleted the shortcut record from SY01990, and the window stopped opening automatically.
There might have been a few clues that we missed that explained how and why this happened, but the details that were found made it a pretty odd problem. Fortunately the fix was pretty easy--once the consultant found the mysterious shortcut record.
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.
Some clients are "lucky" enough to be the ones to uncover Quality Reports for Microsoft. And it seems like some clients do a better job of it than others, or at least it seems that way :) Recently, I have been working with a client who has encountered several bugs within Management Reporter. Now, the good news is that they are all resolved in MR 2012....
But I thought it would be good to document the latest, as my coworkers and others expressed a lot of skepticism when I explained the scenario. They insisted that there must be a logical reason for it. But, alas, there is not any explanation other than it being a Quality Report (confirmed by Microsoft).
Here is the scenario, it assumes that all companies are using the same report set in Management Reporter:
Create a company in Management Reporter, do not include Analytical Accounting in the company configuration.
Create a number of reports in the company. All of the reports generate successfully.
Create a company in Management Reporter (using the same GP database as the company in Step 1), only this time include Analytical Accounting in the company configuration.
Set the new "AA" company as the default.
Take an existing report definition (created in the "non-AA" company) and change the company to the new "AA" company.
Generate report.
Expected results- report should generate, as the account format is the same (since both companies point to the same GP database) and although analytical accounting is enabled for the current company...you are not required to use any of those segments in the row, column, or tree.
Actual results- report yields no data
So, I did some testing and I found that if you use ANY building block (e.g., Report Definition, Column, Row, or Tree) that was created in the "non-AA" company, the report will not return results in the "AA" company. Take the following scenario...
Open a report definition created in the "non-AA" company
Do a Save As, and change the company on the report definition to the "AA" company
Change the building blocks to be building blocks (rows, column, tree) created in the "AA" company
Generate the report, still no data!
Only if all building blocks, including the report definition, are created in the "AA" company will the report pull data.
This is true no matter what building block comes from the "non-AA" company. So, for example, you create all building blocks in the "AA" company but use a column from the "non-AA" company-- no report data.
Confirmed with Microsoft that this is resolved in MR 2012, but wanted to share the info...as this definitely had me baffled :)
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.
Over three years ago, I was helping a client import tens of thousands of transactions into Dynamics GP using eConnect integrations that I had developed.
eConnect worked great, quickly and reliably importing the transactions into Dynamics GP, with full data validation in the process.
But the one thing that eConnect (or Web Services or Integration Manager) cannot do is post batches in Dynamics GP. Unfortunately, Dynamics GP does not have any feature to programmatically post batches, and there is no standard option or feature that will allow you to automatically post batches in GP or even schedule batch posting. You can use the Series Post or Master Posting windows in GP to post multiple batches at once, but that process must be activated manually by a GP user and must be performed separately in each company. If you have dozens or hundreds of companies with intercompany batches in each, posting batches can be a very tedious and time consuming process.
While searching for a Dynamics GP auto-posting solution in 2009, I came across Post Master by Envisage Software, which was a new solution developed with Microsoft .NET that could automatically post batches in Dynamics GP. It could even detect new batches, post them on a scheduled basis, and generate the batch posting reports as text files, PDF files, or send them via e-mail.
Over the last three years, Envisage Software has enhanced Post Master, adding features such as pre- and post- stored procedures that allow customers to execute custom SQL scripts before and after batches are queued or posted in Dynamics GP. Post Master can also be customized to post additional modules, such as Project Accounting transactions that don't have a traditional batch posting process.
Despite the great features of Post Master and it's strong success with Dynamics GP customers, there was still one limitation of Dynamics GP that customers were looking to work around: The need to have Dynamics GP running and logged in to post a batch. As a Dynamics GP Add-In, Post Master requires that the Dynamics GP client be running and logged in. This means that a Dynamics GP client must be kept running and logged in at all times, and that GP login consumes a user license, which essentially costs a customer several thousand dollars.
Over the last year, Andrew Dean at Envisage Software has been developing a brand new product that finally eliminates this limitation.
Envisage Software has just released Post Master Enterprise, an entirely new product that runs as a standard Windows Service and can automatically post Dynamics GP batches without having the GP client running or logged in.
Because it runs as a Windows Service, it does not require an active Windows session, and because it doesn't require Dynamics GP to be running or logged in, it does not consume a GP user license. The Windows Service design is a great benefit for system administrators who previously had to ensure that a GP session stayed running at all times, even after a server reboot. And because Post Master Enterprise does not require that a GP user license be tied up all day, companies can reclaim the several thousands of dollars that they have invested in the user license for a real GP user to utilize.
Post Master Enterprise has all of the features of Post Master "Standard", including full batch posting reporting capabilities, e-mail error notification, batch auto-detection, and automatic retry of failed batches.
Here is a video demo of Post Master Enterprise: (YouTube Link)
If you have a client with high transaction or batch volume, a client with a lot of GP databases that uses intercompany transactions, or a client that has to regularly sit around and wait for large batches to post, Post Master Enterprise has set a new standard for automating the Dynamics GP batch posting process.
I've been working with Andrew Dean at Envisage Software for the last two years reselling Post Master in the Americas. Post Master Standard has been a great success, and I expect Post Master Enterprise to revolutionize Dynamics GP batch posting.
For more information about Post Master Enterprise, you can contact Envisage Software Solutions at:
Steve Endow is a Dynamics GP Certified Trainer and Post Master Enterprise reseller for Envisage Software Solutions. He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.
It's a trite phrase, but I constantly say that "The Devil is in the Details" when it comes to developing integrations.
Some integrations are very simple, while other integrations present you with situations that leave you scratching your head. And some integrations that you think will be very simple turn out to be surprisingly complex for reasons that you would be hard pressed to have anticipated.
One of my clients recently contacted me regarding a small issue they were having with a Purchasing Invoice integration that I developed for them. The integration reads data from a CSV file, then creates Purchasing Invoices and automatically matches them to receipts. It processes thousands of invoices a month and has pretty extensive logic to perform the automatic receipt matching process.
We worked through dozens of challenges and quirks over many months to the point where the original code was spaghetti, but after refactoring most of the integration code, the new version of the integration worked great and was able to handle all of the oddities required by the import process.
Or so we thought.
After processing hundreds of thousands of invoices, the client came across a new requirement.
The issue? One of their vendors is issuing all-numeric invoice numbers that begin with a zero.
No big deal, right? The Dynamics GP Document Number is a text field, so a leading zero shouldn't be an issue. And in that respect it isn't. My integration can process such invoices fine.
But one of the features of the integration is that if any errors are detected in a data file, it outputs a modified version of the CSV data file so that a user can open up the file, make some edits, and reprocess the file. Very simple.
Except when the vendor uses an all-numeric invoice number with a leading zero. If a user opens a CSV file in Excel, an invoice number of "012345" is displayed as "12345". The leading zero is dropped by Excel. The user then makes their edits, saves the CSV, and reprocesses the file, resulting in invoice 12345 being imported into GP rather than 012345.
Technically this isn't an issue with my integration--it's an issue with Excel. But because Excel is the best tool for editing CSV files, we're stuck with this limitation. Unfortunately, there is no easy way to get Excel to retain the leading
zero in a CSV file. There is at least one workaround, but it is tedious
and impractical for my client.
My client reviewed this issue internally and had a discussion with the vendor, and apparently the vendor is unwilling or unable to change their invoice numbers, and my client apparently needs to retain the leading zero on the invoice number.
So I now have to modify the integration to add an alpha character in the CSV file to invoice numbers that begin with a zero. If the invoice number is "~012345", Excel treats the value as an alpha text value. I then have to make sure that this character is removed from the invoice number prior to importing the transaction into Dynamics GP.
Fortunately my integration is designed in a way that makes this change quite easy. But it is a good example of just one of the many unforeseen details that can make an integration more complex than expected.
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.
I believe in the importance of being an advocate in the implementation process, and over the years I have had many discussions with fellow consultants regarding this (some agree with me, some do not). I recognize that consultants, project managers (both customer and partner), and salespeople vary in their approach. Some prefer to provide information while not necessarily forming or voicing an opinion or perspective. Others are very vocal in sharing their experience, perspective, and/or opinion. While others strike a balance between the two. I strive to be balanced, but I know that I definitely end up on the more vocal end of the spectrum.
So why does your approach matter? Well, let's start with some basics about the implementation process:
How many implementations has the consultant been through? Probably anywhere from 2 to 5 to 10 to 50 to a hundred. How about the client? Maybe 1 or 2. And the staff? Most likely none, or maybe 1.
The consultants involved in a project hopefully have "good" implementation experiences under their belt, projects that went well. Too often, if the client has been through a prior software implementation, it was not a positive experience.
Consultants, project managers, and salespeople-- it is our full time job to sell, support, implement, and manage the software. How much time does the client's staff really get to focus on the implementation. If they are lucky, maybe 1 day a week?
Bottom line is that consultants (and project managers and salespeople) generally come to the project with more experience and perspective than the client and staff. Of course, consultants share their product knowledge with the client through all of the phases of the project...but to what degree are they responsible for sharing their perspective that has been informed by their past experiences?
Personally, I think we all have a responsibility to share that perspective and to act as an advocate for the project's best interests whenever possible. Whenever we cease to do that, we leave the health of the project up to chance. Being an advocate, in my mind, includes:
Ensuring that issues are prioritized and addressed in a timely fashion
Willingness to escalate issues and concerns on both the partner and client side when necessary
Having difficult conversations when partner or client resources are not performing adequately-- so often, this is NOT about someone's work ethic or knowledge as much as it is about RESOURCE ALLOCATION (we all know the term 'bottleneck')
Being on the project's "side" when it comes to decision making. Sometimes this means sharing the client's perspective, and other times it means forming your own (which may be contrary to what the client is asking/suggesting/doing). But in the end, I think we should advocate for what will make the project most successful-- in terms of goals, budget, timeline, etc.
Do you agree? Disagree?
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.
Most folks seem to associate the SQL Server 2008 R2 Report Builder (Report Builder 3.0) with SQL Server Reporting Services. And, I suppose, rightly so. I mean, if you use the Report Builder with SQL Server Reporting Services, you can deploy the reports you create to the Report Manager website and allow other users to access and run them. But it seems like a lot of folks don't realize that you can actually use the Report Builder 3.0 much like the Crystal Reports designer application-- to create and run reports on your desktop (wtihout necessarily having SQL Server Reporting Services deployed and configured).
Why is this a good thing? Well, some organizations don't necessarily have a need to deploy reports out to a number of users. Sometimes, it's just one or two users who want to create and generate reports for themselves-- as opposed to developing reports for others. In those situations, you can just download the Report Builder and get going!
When you launch the Report Builder, you will be greeted with a Getting Started window like this:
If you choose the "New Report" option, you can then select a type of report to create and you will be guided through the process of creating a report (as opposed to choosing Blank Report, which will give you a blank canvas) to begin with. Once the report is created, you can save the RDL file to your desktop or other shared location to be run again (just like you could save an RPT file and run the report in Crystal Reports). Or, if you do have SQL Reporting Services configured, you can deploy the RDL to the Report Manager website (but, again, this is not required).
One other concept I should toss out there, if you are going to give Report Builder a whirl, and you have not previously worked with SQL Reporting Services-- the concept of Data Source -vs- Dataset. In Report Builder and SSRS, you have a data source (just like you would with Crystal Reports) that stores the information necessary (e.g., database, server, user login) to connect to the database you want to report on. But in Report Builder and SSRS, you then also have the concept of a Dataset. In the most basic terms, the Dataset is the query used to pull information from the database. For example, a dataset might select data from tables or views in your database. Or it might execute a stored procedure to return results to be used on your report. If you choose to use one of the report wizards to create your report, you will be guided through the process of creating both a dataset and a data source for your report. Also, I should note a couple interesting things about data sets...
1. You can create shared data sets to be deployed to SSRS and used on multiple reports
2. An individual report can actually contain multiple datasets, which can be unrelated...this is particular useful if you are designing a dashboard-style report with different information displayed in different regions of the report
Hope this little bit of introduction to Report Builder, and how you can start using it NOW, helps!
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.
