If it wasn’t clear before, I’m a huge evangelist of using the SQL Server for reporting in DDMS. I’ve spent a lot of hours working with DDMS in a lot of ways, and I’ve always seen its reporting capabilities as a huge weak spot.
A few years ago, I sat down and got serious about learning Report Writer. It was worth the while, overall, since Report Writer is, of course, more than strictly reporting. However, it was unbelievably frustrating to run into the all-too-frequent circumstance where I needed a report that Report Writer couldn’t do, due to the limitations of the Master and Supplemental File structure that was implemented. Worse came to worst, I would write two reports (using their ‘for Excel’ methodology) and use VLookups in Excel to get to the results I wanted.
On that ‘for Excel’ note, in a lot of cases, you almost need duplicates of a lot of reports – one for print, one for Excel. If you’ve ever dumped a print-intended report, or even an SA2-formatted PO, to a file printer and pulled it into Excel, you know you waste huge amounts of time cleaning the data up before it’s even usable. And heavens forfend should you accidentally delete a row or two of data while you’re getting rid of hundreds of rows of headers and assorted other garbage. And that’s after the time you wasted using Excel to import a .txt file.
DDMS does also have the ‘Preview Reports’ functionality. It may be different for people who don’t know SQL, but as I mentioned in a previous post, even some at DDMS recognize that it isn’t an ideal solution. It’s clunky and slow, and not at all intuitive, to my mind.
I’ll set aside the C1 Designer option (along with my feelings on the ‘extras’ in DDMS where getting them involves writing another check) as I haven’t seen it, but I’m not entirely crazy about the new graphical development ECI2 has been doing lately, and I have a feeling the C1 Designer would be along those lines.
So what to do? My answer might not be right for all, but I’ve found a solution that works very well for me and for my company. Under my desk there is an ancient Dell desktop, a Prescott Pentium 4, that is running a lightweight web server. Utilizing a package known as XAMPP, found at http://www.apachefriends.org/en/xampp-windows.html, it is comparatively easy to establish reporting frameworks that will allow you to run any report imaginable.
XAMPP is a self-contained package, utilizing an Apache web server, along with PHP, MySQL, Perl, and a FileZilla FTP server. Using common web languages, you can quickly create a reporting system that has a web interface that will work with any modern browser. With a bit of work, it’s possible to create a reporting system that can be utilized by every employee in your organization simultaneously. If you’re so inclined, you can also implement user-level security to keep employees out of reports they shouldn’t have access to.
Aside from that, you can write reports and use Windows Task Scheduler to run at selected times and email them to selected recipients. While it’s good to have reports available on-demand, I have found it to be the case that there are reports that get forgotten. Oftentimes, a report in your inbox will get worked, while a button waiting to get pushed might be waiting a long, long time.
I’ll follow this post with a series introducing the framework I utilize, along with several reports I use. These are, in some cases, unique to my dealership and the way we operate. In some case they are more universal and might be useful to any office products dealer using DDMS. More to the point, though, I hope to spark your imagination as to what you might use such a framework for. Rather than hunting about in DDMS or going back to your support people at DDMS, you might hop right in and bang out a report you’ve been wanting and haven’t gotten around to yet. That’s a powerful feeling, my friends. And that’s what I’m hear to do – put the power in your hands. As ever, 
Recent Comments