> Document Assemblies    
Document Assemblies


Problems faced when working with document assembly printing

In any system where you send multiple print jobs to the print spooler, the print spooler settings will not ensure that all the documents print in that particular order. The only solution is to have some system in which the print spooler can remain open during this whole assembly and output process or you output all of separate documents into some type of directory with a numbering system.

While you can set the order of the table by using a query, the print spooler in windows is another matter. Some may say that if there ever was one weak area in windows in terms of business applications it would be the print spooler.

If you have experience doing lots of batch processing, you’ll know the settings of the printer spooling system from code is oh so very important on these systems. Typical approach would be

  • "start new spool job"
  • "force spool job stay open"
  • "output + print several documents from several different programs"
  • "close spool job"
  • "print spool job"

In effect the above steps would allow one to "assemble" a set of documents that often come from SEVERAL different programs. Often a typical office task revolves around several programs such as word (cover letter), Excel (rates or calculations) and some type of database system or output from an Accounting system (or billing/quote system).

We REALLY need this ability in windows.

And today, what is worse is now with dual processor systems and new threading issues, you cannot really be sure that the word document you are printing to the spooler will get out first before the excel sheet and pdf document you also attempting to print in this supposed "document set".

The problem of course is often a few documents out of order in a print job can have absolute disastrous effects. Being involved in a system in which several different documents were produced from several different programs have to be run one after another, it’s critical that the output of these documents assemble in correct order.

These documents may be medical diagnosis of patients, and a few sheets placed in wrong order of a batch run would in fact mean that one patient could be incorrectly told that they have cancer, while another patient would be incorrectly told they do not. Now not all applications have such serious results when print order is messed up, but even in situations like sending out the wrong page of an invoice or bill to a customer can have significant effects on customer goodwill. No customer likes the wrong billing totals, especially when NOT in their favor. And even sheets of shipping order messed up in a pile of papers for the shipping room not only results in unhappy customers but one now has to deal with nasty shipping costs. Both customers are mad, and now BOTH must return goods and you again must ship to BOTH customers again - what a mess!

Beyond billing and shipping, even an insurance quote system where we use a word template, some excel documents and perhaps some insurance policy pulled from a custom insurance database will then needs assembly into one nice package. Again any out of order printing can often make the job very difficult for people that remove this output from the printers and package up and ship out that material to customers all day long.

We should spend a little bit of time to consider the above issues, since for many business applications the developers often give little thought as to how such a small issue as printing a few little silly documents out of order can have serious business issues.

In the case of the medical clinic, the discovery of that mistake may cost several days of time since all of the staff had be called in for the whole weekend to go through every single diagnosis and document that had been sent out in the last couple of days to verify that patients had not been incorrectly informed. This huge mess and massive amount of labor cost was due to a little silly print spooling issue that caused some documents to be printed out of order.

As noted so often many jobs are based around a set of documents. For that insurance claim, you have an envelope and cover letter is printed from word (some custom text needed to be entered and edited by the person building this claim). Then perhaps a spreadsheet that has certain rates to help with claims calculations comes from Excel. And then the additional information on policy terms comes from a database report and insurance reporting system you built in Access. All these documents must then be sent out to the customer. And of course the summer student hired to take the output from the 4 laser printers that you're running at full blast all day with all these documents constantly coming out means any pile out of order becomes very difficult for the person taking that output and documents.

So, the lesson and the moral story here is developers often fail to realize how important order and assembly of documents is.

Using a universal file format to assemble the documents

It’s strongly suggested that you come up with some type of universal output (such as PDF) and numbering system for the PDF documents. You THEN AFTER outputting the documents with some type of number system, you next run some code to take all of those documents and assemble them into one single PDF document, and then print that (that way the pages and material inside is guaranteed to be in your correct order).

A system that allows you to use com object automation, and pull documents together and assemble them into one then print or create a new PDF document is the free open source library here:


Note that after you install the above PDFcreator system, there are some REALLY nice windows scripts (vbs, and suitable for VBA) that have examples on how to assemble documents together. These sample scripts are installed in some sub folders of the program dir used during installation.

And of course if you can setup ALL OF the above to occur in one report run from inside of access, then you eliminate the multiple document assembly problem. So it's often worth it to put a lot of extra hard work to cook up a way to produce all output in one report. Often sometimes we developers are a bit lazy, and often we send off multiple reports when some type of report grouping would suffice.

The above article was originally based of a post by Albert Kallal, which can be found here