Snippet: Print a Financial Batch Summary

  • By Michael Garrison 2 Years Ago

When Rock v1.0 was released, there were a few items missing on the Batch summary pages that our Accounting team wanted to print out each week and file away as a summary. For a while we used a custom report that I cobbled together, but fortunately those days are gone and the summary page now lists totals for the batch, totals per Account and totals per Currency (Tender).

Only one thing is still missing: a Print Button. Sure, you and I know that you can highlight the desired section and choose to print "Selection", but that can be unreliable in training volunteers and hoping they remember week after week. (Failure to remember ends up in printing the full page, including a list of all the transactions in the batch- which is both wasteful and a privacy issue if they don't dispose of the extra pages properly).

But, since Rock is so wonderfully extensible, let's go ahead and add our missing Print button!

To start off, notice that the New Batch page is the same page as we use to view old batches (~/page/163 by default). The only difference is that a New Batch is the 'normal' view of the page, and an existing batch is called when the URL is appended with the batchId parameter. We only want the Print button to show up when we're viewing an existing batch.

How you do this is up to you- JavaScript (within the summary's Post-HTML section or an HTML content block) is probably the most logical (and easiest on your server), but I chose to use a Dynamic Data block instead, to keep my code short and since the query we need is only a very small burden on the server. (If you want to eschew the DynamicData route, you'll just need to check the URL parameters using JavaScript to see whether BatchId is set or not).

This post has been heavily edited- click if you want to see the old content

So to start, view an old batch (or go to the "new batch" page). Click the "Block configuration" button on the Admin bar by hovering your mouse at the bottom of the screen. Hover over the arrow at the top left of the batch summary block and click the "Block Properties" button on the fly-out menu

Switch over to the Advanced tab and add the following to the "Post-HTML" field:

{% if PageParameter.batchId > 0 %}
<script type="text/javascript">
$("fieldset[id$='_fieldsetViewSummary'] > .actions").append("<a href='javascript:printBatchDetail()' class='btn' id='printbutton'>Print</a>");
function printBatchDetail() {
            var divContents = $(".batch-detail").html();
            var printWindow = window.open('', '', 'height=400,width=800');
            printWindow.document.write('<html><head><link rel="stylesheet" href="/Themes/Rock/Styles/bootstrap.css?v=635646854620942638"/><link rel="stylesheet" href="/Themes/Rock/Styles/theme.css?v=635646858861959605"/><link rel="stylesheet" href="/Styles/developer.css?v=635646854544537576"/><title>Batch Summary</title>');
            printWindow.document.write('</head><body >');
            printWindow.document.write(divContents);
            printWindow.document.write('</body></html>');
            printWindow.document.close();
            setTimeout(function() {printWindow.print();printWindow.close();}, 500); //setTimeout required because Chrome tries to print before it finishes writing the document
        };
</script>
{% endif %}

We're wrapping our script in the {% if PageParameter.batchId > 0 %}{% endif %} conditional so that it only runs if a row was returned. Then we're leveraging JQuery to find the element with class actions within a <fieldset> element whose id attribute ends in _fieldsetViewSummary. Then we're using append() to write a link styled in Bootstrap to look like a button.

When that link is clicked, it calls the printBatchDetail() function we define in that Javascript, which grabs the HTML contents of the element with class batch-detail and writes that content (along with typical webpage-wrapping tags and CSS links which I copied from a normal Rock page) to a pop-up window. Then it pauses to make sure that Chrome actually renders the page before triggering the print() function and closing the pop-up.

Now, depending on your users' browser configuration, they may get a warning that the pop-up was blocked. If they choose to temporarily allow pop-ups, the page reloads (not an issue here since there are no POST variables to get resubmitted or interaction-triggered dynamic changes to the page) and the print button will work this time. Or they can choose to always allow popups from your Rock site and it will be a once-per-computer-profile configuration. Long story short: a good experience for all!


@mikejed
Spark Development Network
Flagstaff, AZ

Michael Garrison recently left his job in Architecture to become one of the "new guys" at Spark (the "Core Team"), but he's still helping out Christ's Church of Flagstaff and other non-profits with tech needs in his off-hours, trying to make computers do what computers do best, so that people are freed to do what we do best: relate with people!