11 replies to this topic

[LukeNeet]

We need to print the invoice number as a barcode on an invoice document.

Has anybody done this?

[Mike Wright]

Hi,

We print barcodes (to identification labels mainly) - and we use dedicated Zebra printers.

There's quite a few printer types out there that can handle barcodes. You just need to know the corresponding programming language (ZPL II in the case of zebra printers) and chuck the code straight at the printer (we write it to an ascii file and output with lp -d in Unix). There's also simple GUI based code generators for most of these barcode printers, which takes a lot of the clever work away (which is nice)

I'm sure there's other ways of generating barcodes - this is just ours.

HTH

Mike

[Lewis Mccabe]

Certain printers are easier than others to implement but generally bar-code printing is not difficult. Just give the appropriate string and the printer will handle the rest. If you are using dot matrix printers (impact), the printer will usually (depending on make) print the bar-code completely and then return to continue text print where it left off. Will you be using a specific make printer? We print barcodes quite well on the OKI impact printers.

Lew

[andykay]

Hi Luke,

There are third party report applications out there that can easily do what you are requesting. We use JetForms here to do what you are seeking to do, as well as, produce PDF's of quotes that can be stored and Emailed to clients. It has an expensive initial start cost but is a realatively easy program to use that can produce Emails, PDF's, Checks for your AP, and professional looking reports that have barcodes.

Here's a link for you to read a little about it.

http://www.proivrc.c...d=1&hl=jetforms

Good Luck,

AK

[Rick Young]

It also depends which "font"/style/symbology of barcode you wish to use. A decision made by one of our customers was to use Code-128-Autoswitching for product barcode labels (via Zebra printers) and also for barcoded document numbers (via laser printers). The latter was later switch to be Code 39 (aka Code 3-of-9).

To handle the Zebra printing, we produce straight ASCII files of ZPL code, which are then sent to the Zebra printers. I did not have a hand in it myself, but I believe that the customer's IT dept tweaked the HP-UX print filter in some way - I suspect just to strip out any "automagically added" stuff so that what I sent, was verbatim what was received.

To handle the document barcoding, we send PCL codes as $$vars in ProIV report functions. Caveat: the style of printer the client elected to use was the Lexmark Infoprint 1352 and it required an additional fontcard.

Both of the above are in daily use today, and have been for 12+ months.

Edit for an additional piece of info: prior to the laser printed barcodes, we did have some dotmatrix barcodes in place, which just required a lot of reading of the printer manuals to figure out the right codes to send. These dotmatrix barcodes were discontinued, as the barcodes were not reliably readable with barcode OCR after being imaged, and had something like a 60% success rate with some of the barcode readers being used by the customer.

-Rick

Edited by Rick Young, 28 September 2006 - 07:17 PM.

[Lewis Mccabe]

Rick,

Were those dot matrix read problems with the 25 pin as well as the 9 pin models? We don't have read problems with the 25. We have not as of yet implemented electronic document management. That will be shortly. I do not want to go laser just yet if I don't have to. Was there no solution to your dot matrix read errors?

Lew

[Rick Young]

I believe that the customer's printers were predominantly (but across 35+ physical locations, there is no guarantee of consistency) Epson FX-80's. Off the top of my head, I don't know for certain, but believe that these are 9-pin.

If the individual printer was "new" and/or clean and the ribbon was new and the planets were aligned correctly..., then the read was good - however, across this many locations with the volume of documents, the fail rate was far too high. Their main concern was the OCR issue, rather than the handheld or tethered scanner issue. Every test I ever performed with a handheld or tethered scanner was successful - therefore, if your (or the OP's) barcodes are destined to be read in this manner, dot matrix is likely to be ok.

-Rick

[Mike Lowcock]

Not sure if you are Windows or Unix based. We have done it in Windows by creating an acscii file that contains the 11 ascii codes required to print the next n characters as a barcode. We use OKI printers.

This ascii file we call barcode11.txt and we keep in the root directory of all clients that need to print barcodes.

We then #X=System("GUI copy c:\barcode11.txt LPT1:")

The first thing PRO-IV prints then is the delivery note number which is printed as a barcode. The printer will then revert to normal printing.

This doesn't seem to upset the line count in the report.

It works!

Regards

Mike Lowcock

[Lewis Mccabe]

For those of you who use OKI printers - we use the following global logic to build OKI barcode print string:
PARMS($DATA,$BARCODE_SYMBOLOGY,#HT_INCHES,#HT_TWELFTHS_INCH,$BAR_SPACING,$PRINT_HUMAN_READABLE)

// This returns a string to print a barcode on OKIDATA - 390, 490, and 590 series.
// Parameters
// $BARCODE_SYMBOLOGY can be UPCA, code 39, code 128 - I'm sure it does others but these
// are the ones we use

// $BAR_SPACING
// 100 is smallest
// I tested 222 and that was quite large - code 39 8 chars was 2.75" where 100 was 2.5"

DEFINE $BARCODE_PRINT_STRING(80)

//Oki print requirements
// POSITION:
// 1-4 - Setup - DATA SECTION 1
// 5-6 - Barcode symbology (UPC, 39, ETC) - DATA SECTION 2
// 7-8 - Barcode height - DATA SECTION 3
// 9-11 - Bar spacing - DATA SECTION 4
// 12 - Human readable flag - DATA SECTION 5
// 13-15 - Command telling printer data to follow is barcode data - DATA SECTION 6
// 16 - Length of barcode data - DATA SECTION 7
// 17 to length of above number - Barcode data - DATA SECTION 8

// #### DATA SECTION 1 - setup
$BARCODE_PRINT_STRING = CHAR(27) + CHAR(16) + CHAR(65) + CHAR(8)

// #### DATA SECTION 2 - barcode symbology
// UPC-A setting is 10
// Code 39 setting is 20
// Code 128 setting is 40

CASE $BARCODE_SYMBOLOGY
WHEN '39' : $BARCODE_PRINT_STRING = $BARCODE_PRINT_STRING + CHAR(2) + CHAR(0)
WHEN 'UPCA' : $BARCODE_PRINT_STRING = $BARCODE_PRINT_STRING + CHAR(1) + CHAR(0)
WHEN '128' : $BARCODE_PRINT_STRING = $BARCODE_PRINT_STRING + CHAR(4) + CHAR(0)
OTHERWISE : UMSG('Global logic RBAROKI - Invalid symbology - value=' +
$BARCODE_SYMBOLOGY,-1)
RETURN('')
ENDCASE

// #### DATA SECTION 3 - height in inches
$BARCODE_PRINT_STRING = $BARCODE_PRINT_STRING + CHAR(#HT_INCHES) +
CHAR(#HT_TWELFTHS_INCH)

// #### DATA SECTION 4 - Bar spacing -

$BARCODE_PRINT_STRING = $BARCODE_PRINT_STRING + CHAR(CONV($BAR_SPACING(1,1))) +
CHAR(CONV($BAR_SPACING(2,2))) + CHAR(CONV($BAR_SPACING(3,3)))

// #### DATA SECTION 5 - human readable
IF $PRINT_HUMAN_READABLE = 'Y' THEN
$BARCODE_PRINT_STRING = $BARCODE_PRINT_STRING + CHAR(1)
ELSE
$BARCODE_PRINT_STRING = $BARCODE_PRINT_STRING + CHAR(0)
ENDIF

// #### DATA SECTION 6 - command telling printer data to follow is barcode data
$BARCODE_PRINT_STRING = $BARCODE_PRINT_STRING + CHAR(27) + CHAR(16) + CHAR(66)

// #### DATA SECTION 7 - length of barcode data
$BARCODE_PRINT_STRING = $BARCODE_PRINT_STRING + CHAR(LEN($DATA))

// #### DATA SECTION 8 - actual barcode data
$BARCODE_PRINT_STRING = $BARCODE_PRINT_STRING + $DATA

RETURN($BARCODE_PRINT_STRING)

[mdexter]

Okidata dot matrix printers!!?? Do they still make these? Takes me back to the good old days. Televideo terminals, making your own 25-pin cables (I've still got the crimping tool around here somewhere ...). I feel old all of a sudden. Mark Dexter

[Lewis Mccabe]

Mark, you go that far back? If I ever need a 25 pin cable made, I will call you. Oh... never mind. I found my crimper. It was next to the Wordstar floppy.

[Rick Young]

8" floppy that was sitting on top of the 12" diameter 10MB diskpack beside the cardpuncher?