SSRS is a great (and most importantly free) reporting writing tool and its inclusion into the Dynamics framework is an obvious and natural progression for Microsoft.
 
** However **
 
When it comes to things like creating data-merged documents for “print-publishing”; SSRS has its serious limitations. The developer faces numerous challenges when attempting to replicate “professional” customer-facing documentation. Things like “duplex-printing” (for terms and conditions on reverse) or “page-sequence-masters” (for interspersed cover letters) or even changing the “page-orientation” in the middle of a print run (for portrait to landscape pagination) are almost impossible to achieve in SSRS.
 
Q: “Why would you want to do all those crazy things in a report-writer?”
 
A: Well, customer-facing documentation often needs to utilise use of “all-of-the-above” in order to produce professional documentation to send to the customer. The standard out-of-the-box report offerings for things like packing slips, credit control letters or even invoices often do not meet the high-standards required for most firms. Inevitably most of these processes are “farmed-out” to 3rd party print providers.
 

·         For example, when you receive your utility-bill you will often open a nice cover letter requesting payment, followed by an invoice and remittance advice. Each of the pages may be oriented differently (e.g. cover letter being portrait and remaining pages landscape). There maybe contractual terms and conditions printed on the reverse-side of the invoice, and the invoice may spill over several pages. You may even receive a remittance advice offering you different ways to pay along with a tear off bank-giro slip for your convenience.

 
All of this is extremely hard to do in SSRS, especially if it has to be done in “one-print-run”.
 
As an X++ developer there are some workarounds and you can now do some pretty clever stuff, but you can’t do everything required to replicate a true desktop-publishing application. The conventional approach would be to output an SSRS genared PDF page for every unit of data within your print-run and then collate these pages with any that need to print in duplex and sequence them with any associated “inserts”… complicate stuff!
 
The fundamental problem with this approach is that you can’t control page overflow. As soon as SSRS hits the print limit boundary it will initiate overflow-handling and attempt to finalise the print according to the way that spillover pages have been defined. There is nothing that can be done to tell the SSRS engine that it needs to stop printing the current PDF and start a new one (to allow for "page-inserts").
 
Even considering the alternative of using Dynamics Office Integration doesn't work as dynamic data merging cannot take place into documents that must retain their fixed format. At the moment the "out-of-the-box" merge functions are not clever enough to reformat the overflow page when data exceeds its print boundaries (merge regions simply re-size dynamically). This means that a table will simply extend onto a new page instead of re-initialising the page and flowing into the original print region (defined on its predecessor).
 
What I hope to do in my next post is to show how we can overcome these problems using WPF. The work to create a WPF "fixed-format-document" is more extensive, but its not complex and it means we can overcome all of the obstacles identified in this article.
 
Until next post…
 
REGARDS