One of my clients upgraded from a Troy 4300 to a Troy 4350 model. The old one was starting to have problems, the bank was complaining, and overall it was a necessary investment. The problem was that the escape sequences necessary for printing the MICR fonts and accessing the Signature card were slightly different. But no one realized that until the printer was here.
When it arrived it was installed and a test check run was sent to it. It didn't exactly get the expected result. The MICR font wasn't MICR, and the complete signature didn't print. After tweaking the control codes and asking the user to "try again" and "tell me what it looks like" over the phone for the upteenth time, it was time to do something different.
The only way I've ever been able to get a check printing program working with a check printer is to either sit the developer next to the printer, or move the printer next to the developer. This time we were able to move the printer next to the developer, which allowed the developer to see first-hand what the problems were and to try multiple iterations of code quickly.
Here were some things I was reminded of as I worked with the developer to resolve the problem:
When it arrived it was installed and a test check run was sent to it. It didn't exactly get the expected result. The MICR font wasn't MICR, and the complete signature didn't print. After tweaking the control codes and asking the user to "try again" and "tell me what it looks like" over the phone for the upteenth time, it was time to do something different.
The only way I've ever been able to get a check printing program working with a check printer is to either sit the developer next to the printer, or move the printer next to the developer. This time we were able to move the printer next to the developer, which allowed the developer to see first-hand what the problems were and to try multiple iterations of code quickly.
Here were some things I was reminded of as I worked with the developer to resolve the problem:
- When running to a Troy printer from an SQR, be sure to select HP as the Format on the Process Scheduler Request screen. Printing to PS (postscript) will make the printer ignore all of your control codes and printing with a TXT format will ignore all formatting altogether.
- PAY003.SQR really only has a few places (two I think) where changes need to be made. Don't look for problems where they don't exist.
- If you need a sanity check, write a stand-alone SQR or Crystal that does nothing but print the MICR font and the Signature just to make sure you know how it's done.
- The bank can provide a MICR ruler to make sure the characters line up.
- Be sure your testing involves sending a batch of voided checks to the bank for their approval
- Give the "check printing program modifications" tasks a generous number of hours when doing a project plan.
Set as favorite
Bookmark
Email this
Trackback(0)
TrackBack URI for this entry
Comments (10)
Subscribe to this comment's feed
written by Jarod, December 04, 2006
Is there any trick to getting SQR to send the right thing to the printer? I know I have the right codes to print our signature and the MICR font (on an HP 9050 with TROY cartridges), but it just won't work even in a standalone SQR.
-
- +0
-
-
written by Brent Martin, December 04, 2006
When you run the standalone SQR from a command line, make sure you specify the -PRINTER:HP flag to force it to use the HP control codes. The PostScript format will print, but will ignore all control codes.
Otherwise, send the sample file to the printer just to make sure the MICR and Signature fonts will print at all. If that works, change your standalone SQR to send the same characters from the sample file. Use a hex editor (UltraEdit has one) to see the control codes, manually translate them to decimal, and use the Encode command in SQR to build the string that you'll send to the printer.
I apologize if these suggestions are too obvious. Good luck!
Otherwise, send the sample file to the printer just to make sure the MICR and Signature fonts will print at all. If that works, change your standalone SQR to send the same characters from the sample file. Use a hex editor (UltraEdit has one) to see the control codes, manually translate them to decimal, and use the Encode command in SQR to build the string that you'll send to the printer.
I apologize if these suggestions are too obvious. Good luck!
-
- +0
-
-
written by Jarod, December 05, 2006
Do you know why it doesn't work using -PRINTER:WP? That is what I was trying to do for the longest time when I finally thought that maybe if I ran it to a .lis and used TROY's utility to send it to the printer it might work (and it did). I'm guessing that it somehow forces using a Postscript driver, but I'm not sure how.
Oh well, thanks a bunch. Your original post kind of clued me into what I was doing wrong after I re-read it.
Oh well, thanks a bunch. Your original post kind of clued me into what I was doing wrong after I re-read it.
-
- +0
-
-
written by Brent Martin, December 05, 2006
The goal is to dump the character sequences to the printer in a "raw" form. -PRINTER:WP uses the Windows default print driver which will strip off control characters, as will -PRINTER
S. -PRINTER:HP uses HP control codes which work because Troy is basically an HP printer, and because it doesn't strip out any control characters.
Anyway, I'm glad you got past your problem. Best of luck getting the bank to accept your checks!
S. -PRINTER:HP uses HP control codes which work because Troy is basically an HP printer, and because it doesn't strip out any control characters. Anyway, I'm glad you got past your problem. Best of luck getting the bank to accept your checks!
-
- +0
-
-
written by Brian, December 18, 2006
This post helped me get close. Our recent Troy upgrade moved our signature image from one line to four lines(the font blocks are smaller). The font prints 6 lines per inch and PAY003 is set up to print 8 lines per inch. So our signature overlaps itself. Has anyone else run into this? Is it possible to adjust the line height for just the signature section?
Thanks for your time.
Thanks for your time.
-
- +0
-
-
written by Brent Martin, December 19, 2006
I've never had to change the lines per inch in SQR, but you might look at the DECLARE-LAYOUT directive with the LINE-HEIGHT parameter.
-
- +0
-
-
written by Brian, December 29, 2006
I found the line-height parameter in the default-layout section of an sqc that pay003 calls. When I change it from 9 to 12 the signature prints fine, but the rest of the "report" is trashed. I can't see a way to call a different line height for a small section within the page, so it looks like an all or nothing proposition. Does that sound correct?
-
- +0
-
-
written by Brent Martin, December 31, 2006
Unfortunately I think you're analysis is correct -- line height has to be the same for the entire report. You might go back to Troy and see if they can re-do the signature font for 8-lines per inch, otherwise you may have to reformat the entire paycheck for a 6 lines per inch format.
Good luck!!!
Good luck!!!
-
- +0
-
-
written by Brian, January 05, 2007
Success! I figured out how to position the cursor with an escape sequence and using DPI x and y values. My block of code follows. There may be a more elegant way to do this, but it works for me. Thanks for the help.
Brian
---------
encode '*p1525x2885Y' into $Posit1
encode '*p1525x2935Y' into $Posit2
encode '*p1525x2985Y' into $Posit3
encode '*p1525x3035Y' into $Posit4
let $sig1 = $Posit1 || chr(34) || '#$%&' || chr(39) || '()'
let $sig2 = $Posit2 || ',-./0123'
let $sig3 = $Posit3 || '6789:;
Brian
---------
encode '*p1525x2885Y' into $Posit1
encode '*p1525x2935Y' into $Posit2
encode '*p1525x2985Y' into $Posit3
encode '*p1525x3035Y' into $Posit4
let $sig1 = $Posit1 || chr(34) || '#$%&' || chr(39) || '()'
let $sig2 = $Posit2 || ',-./0123'
let $sig3 = $Posit3 || '6789:;
-
- +0
-
-
Write comment
