- Submitted by:
- Kevin Heidt
- PSC Info Group
- Submitted on:
- 30 Mar, 2011
- Powerful Communication Award
Here is some Pres code which sets the Y position of the outbound address to the top for the first page, and the bottom of the second page. Then it uses the Start XY and Ending XY coordinates to make PCL comments that are then added into the print file.
I made a simple VDE script that just moves the window of interest to the right a little bit. The top of the picture shows that the variables used for XY positions are hard coded. The middle part shows the PCL comments that are for page 1, which are then extracted to override the hard coded XY positions. The bottom of the picture shows the XY positions for page 2.
PSC Info Group is a printing and mailing firm headquartered in Oaks, PA. We accept data from various clients, most of which are collections or medical in nature - in almost any data format - and turn it into quality prints which are then mailed at a discounted postage rate. We also have a printing facility in Reno, NV that is designed to allow mail to be sent to any location in the United States with a minimum delivery time.
PSC Info Group has existed for about 20 years now, and originally consisted of a single employee, named Joe Greco, and his van which had a printer in the back. He would drive to the client’s location and do their printing right then and there. We’ve come a long way since then, and now have over 200 employees which are located all over the US, and have increased our number of clients to more than I can count. We pride ourselves in being able to accept almost any file format you can think of, and producing elegant letters and statements that can be customized to the client’s content. All of this happens every day via our automated process which allows us to process, produce, and print our mail in a very small timeframe in order to get it into the mail stream as quickly as possible.
Our ultimate business challenge is one that never changes and is one that applies to almost every other company: Get everything done as fast as possible, as cheap as possible, and as accurately as possible. That’s pretty vague, but it’s very true, and every other individual business challenge that arises is directly connected to that challenge. So how do we address each of the three parts of this ultimate business challenge?
FAST: Since our entire process is designed to be as automated as possible, we put a lot of thought into trying to foresee future variations and then make preparations ahead of time. This is often very difficult to do due to the large number of small custom setup variations that naturally come along with having a large number of individual clients. Consolidation is also important when it comes to speed, because the more work we can combine together and take care of all at once, the less time we have to spend each day for switching from one print setup to another.
CHEAP: In the case of our business challenge, “cheap” in this sense does not only mean dollar amounts, but time as well. So if a change is needed that affects one hundred clients, it is much “cheaper” to have to make the change one time in a single location than it is to have to make the same change one hundred times in one hundred locations. Not only is it faster, but it eliminates the possibility that one of those one hundred changes will be incorrect. Same thing with the printing department. If there are 5 jobs that all have the same characteristics, it is much “cheaper” to set up and break down those characteristics a single time and then print all 5 jobs at once than it would be to set up and break down one at a time for each job.
ACCURATE: This is pretty straight forward. Nobody wants to hire a company that isn’t going to do their best to have 100% of their data generate documents that are 100% correct in which 100% of them are printed, inserted, and mailed.
One of the biggest and most effective solutions that we put into place in order to increase all three of these key factors is the Pitney Bowes EMTEX solution, which was done 2 years ago. I believe it has since been renamed to PI Output Manager, but I will forever know it as “Emtex”, so please forgive me for referring to it as such hereafter. Since I’m writing this for a Pitney Bowes contest, I’m going to assume that there is a general understanding of the Emtex and File Audit solution, and will just mention some key points that pertain to this submission.
From what I am told by some of the Pitney contacts that I interact with regularly, the way that we use the Emtex solution is a little different than the way most companies do. Most companies have an operator that works directly with the Emtex GUI for submitting jobs through it, and then have it drive a connected printer to do the actual printing. The operators are also responsible for appropriately handling any exceptions that may arise. Since there is a person or people dedicated to working with the Emtex portion of their printing process, it is entirely feasible for these companies to have profiles and VDE scripts that number in the hundreds. Some of these companies even use actual data files as their input files, and use Emtex as their document creation software.
We, however, do things differently. We use software called Pres for our documentation creation because it’s robust enough to make it easy to use almost any file format as input data. This software has many types of possible formats as far as print file output goes, but we use PCL for our output because originally we only had HP printers. Once the print file is created, it sits in a holding area on the network until our print operators are ready to print it. At that time, our homemade software will move the file to a specific hot folder based on the printer that the operator wants to print to, which is one of the several folders that Emtex constantly watches. At that point, Emtex will read in the PCL file, perform the input VDE script actions, merge the input file with other input files if necessary, and then perform the output VDE script actions as it creates a new PCL output file. This output file is then printed by that same homemade software.
As you can see, we use Emtex as an automated and unmanned solution for document reconciliation. Since Emtex is a central point of which 99.5% of all our work runs through, we also use it as our IMB solution, since the sequence number in the IMB needs to be unique for 45 days. Most of the time we actually have the Output Manager set to “Unattended Mode” so that any errors that occur will not hold up other files from processing since the GUI is not watched regularly. Since our Emtex solution is automated, we use what we refer to as a “form code”, a 3 digit code that is a character followed by two numbers, to control the different characteristics of the print job that processes through Emtex, such as paper size, coordinates and sizes of certain key pieces of information on the page, how pages after the first page of each document are handled, and the locations of the 2D barcode that’s used for File Audit as well as the IMB barcode. Most of these characteristics are set in the profile by performing a LOOKUP command on a text file which lists all the individual characteristics for each form code, such was which PI Wizard VDE script should be used as the output VDE script.
So now we get to the specific Business Challenge that we’ve been facing with the Emtex solution. As I mentioned, 99.5% of our work processes through Emtex, which means the VDE scripts that I currently have set up need to be robust enough that 99.5% of our work can use at least one of them. Currently we have 6 IMB service variations of 34 form codes, which means we have 34 PI Wizard applications to maintain, but 204 different scenarios to choose from. Some of these form codes are exactly the same except that the outgoing address location is at the bottom of the page instead of the top. Some are set to have the outgoing address in the same location, but handle the additional pages of a document differently. Should a 2D be added to the additional pages? Should the additional pages of a document have the outgoing address area shifted to the right just like the first page did because it’s a medical statement that has the address on the additional pages as well, or should it not have the area shifted because the additional pages are the large bodies of text of a collection letter in which doing the shifting would cause overprinting. Some of the form codes have just the IMB 1/8 of an inch higher than normal due to some custom preprinted stock for a specific client. Is the job letter sized or legal sized?
Since all of these characteristics are set in the Emtex profile at the beginning of job processing, we aren’t able to batch multiple jobs together for merging in Emtex if they have different form codes. So in my previous scenario of doing 5 setups for 5 jobs, if all 5 of those jobs have the same paper types, folders, envelopes, and reply envelopes, they normally they would be printed at the same time. But if two of the jobs have a form code “M13”, another has “M10”, the fourth has “A10”, and the fifth has “M15”, then we still need to do 4 separate setups, because the form code that the job is set to is another criteria for merging jobs together. Therefore, the more variations we have to set up for, the less we are able to merge jobs together, and the slower we are with our overall printing process. Furthermore, whenever a change is required, I have to make that same change to all 34 VDE scripts, testing and validating each one, and then republishing them. As we start to use the IMB more with the phasing out of the postnet and planet barcodes, the number of scenarios and amount of variance will continue to increase, causing our productivity to decrease.
Previously we had no way of communicating with the Emtex solution in order to try to minimize the need to have so many form code variations prebuilt for certain scenarios. The only system that has the necessary information is Pres, and not only does our version of Pres not have any external communication functionality, but it also would be useless because the creation of the print file is asynchronous with the processing of the print file through Emtex. So it looked like the best we could continue to do is have Emtex be a stand-alone system that we prepare our print files to process through by updating our Pres scripts based on the knowledge base documentation that is maintained outlining the aspects of each form code. Both systems act independently of each other and are both set up with the assumption that the other one is on the same page.
Recently there were many changes made by both the Pitney Bowes team and myself which allow us to do our own Presorting in-house. Most of the work had been done by Pitney, but I was able to make some of the extra changes myself, thanks to the VDE training that I received from Gregg Goldstein, and with some guidance by Richard Cayemitte. While I was making these changes, I looked very closely at the work that the Pitney team had done, specifically where page elements and comments were being added in order to have information carry over from the input VDE script to the output VDE script without affecting the physical items of the document. That’s when I asked myself “Does it matter to the VDE script how the comment was added, and by what?” So I started testing with Pres to see if I could add a comment to the PCL print files which could then be seen by Emtex and can be used the same way by the output VDE script as the comments added by the input VDE script. Turns out the answer was no, it does not matter to the VDE script, and yes, it IS possible. It ended up being as simple as the PCL code: "\x1B%0BCO\x22TESTCOMMENT=FRONT\x22\x1B%0A".
The result of this change is that we drastically reduced the number of form codes that are necessary to maintain because all the locations and characteristics that were different from VDE application to VDE application can now all be handled by a single VDE script that uses the information that are embedded by Pres in PCL comments We no longer have to try to adapt our print files to fit into one of the form code templates by manipulating Pres, or create a new form code for a print file that won’t work with any of the existing form codes. Pres knows the exact size and position of the outgoing address block, the IMB location that would work best, what should happen with the additional pages, the size of the paper for each page, and all this information can be passed along to Emtex right inside the print file. It doesn’t even matter if any of this information changes from page to page, or from document to document, because the Emtex VDE script gets the Pres instructions on each and every side.
Not only does this mean that we can batch and merge significantly more jobs together than before which increases our efficiency quite a bit, but we can also pass along to Emtex key information that is generated by Pres. As I mentioned, Emtex is our solution for applying IMBs to our work. However, when we receive information back from the USPS regarding a certain IMB, the other information that needs to accompany the USPS info is generated by Pres and stored in a database. Providing key info to Emtex from Pres will greatly simplify our process of linking the Emtex-generated IMB with the Pres-generated return data, reducing the complexity of the process, and server overhead, significantly.