Use the auto-entered serial number. You can pad it with leading zeroes.
But also pay attention to the requirements needed for the type of bar code you plan to use. Some require that one of the digits of the bar code be a "check digit" calculated from the others. The exact formula varies with the type of bar code and can usually be found quite easily via a web search. You can also find custom functions that compute check digits for different bar code types for you if you don't care to set up your own calculation.
If you need such a check digit, then you use one field for the auto-entered serial number and a second, calculation field that uses the serial number but also computes the additional check digit.
A simple expression that pads a serial number with leading zeroes:
Right ("000000000" & SerialNumberFieldHere ; 9 ) //select a text result type
thanks Phil, thinking about going with one that just has the rules it has to start and end with A, B, C or D. What if I wanted to make something like this?
But make sure are all unique, when a new record is made?
If it's an auto-entered serial number, it will be unique.
Why does it have to start/end with A, B, C or D?
In any case, if the number is unique, adding those letters to the begin/end of the string will not prevent it from still being a unique value.
It sounds like you're talking about Codabar. If you definitely want a 1D barcode, and you don't have any other particular technical or interoperability requirements in mind, I suggest you look at Code 128 first. If your data is numeric only, it can be roughly half as large as Codabar. If your scheme changes in the future, it supports the full ASCII character set. The symbology does have a funky check digit, but the barcode scanner should not be returning it to you, and most barcode creation techniques will take care of adding the correct check digit for you.
Even if your barcode doesn't have a check digit or your creation/scanning tools handle it transparently for you, it's worth considering adding one of your own anyway. Except for UPC/EAN barcodes, most barcodes with check digits only get the validation benefit when scanning the barcode. Scanner failure and degraded barcodes happen often enough that it's a common best practice to print a "human readable interpretation" (HRI) next to each barcode for manual entry when necessary. If it would be obvious from context that a mis-entered ID was wrong, don't worry about. If not, verifying your own (additional) check digit could catch data entry errors. The check digit built in to Code 128 (for example) doesn't validate manually-entered data. There are many schemes you could consider. If you want to keep it simple and stick to just one extra digit for a check digit, I suggest the Damm algorithm. I've already written custom functions to create and verify Damm check digits. If you want to get really fancy, I've seen people adding multiple digits based on CRC-16 (implemented for FileMaker here).
Thanks all, yes I was considering using Codabar as it seemed the most user friendly to create / work with - I think it can be any numbers (and any length) and the only rule is it has to start and finish with A, B, C, or D. It also scans when you use your iphone on it.
I've tested a Code 128 I have in an example solution of barcodes and it doesn't scan when the iphone tries to read it. Below is the attached example I was testing.
A test on a computer screen may not be representative of how a scanner will actually read it if the space allowed for the barcode on-screen doesn't allow at least one full pixel for each "module" in the barcode. If you want to use 9-digit numbers, why are you testing barcodes with 21 ASCII characters? A Code 128 barcode with 9 numeric digits only will be substantially shorter. You can also adjust by making the barcode field (or webviewer object, if that's how you're generating the barcode) larger.
Another testing alternative is to use FileMaker Go's Insert from Device script step. You can set it to scan a barcode from a container field rather than a camera. (It still only works in FileMaker Go on an iOS device, though.) This circumvents any limitations of the computer screen or device camera. This is (part of) how I test Barcode Creator.
Many thanks, the Code 128 seems to be scanning ok now. Might be a good option as it can include letters and a few things like underscore etc. What are the rules on setting a script to auto make a unique one when a record is made? DOn't fully understand the whole check digit thing...
To produce a bar code you set up a calculation field that computes and appends the needed check digit to the data you want encoded. You then format that field with the correct bar code font and you are good to go.
You can web search the check digit algorithms/formulas for different bar codes such as:
For this bar code font
And you can go to web sites that share FileMaker custom functions to find custom functions that compute the check digit for you for just about any bar code you want to use.
There are many blog posts describing how to generate barcodes in FileMaker. This one is the most recent.
If you use one of the plug-in or script-based products for generating barcodes, you shouldn't have to worry about any check digit required by the barcode symbology at all. (I did suggest adding your own as a possible enhancement, but don't worry about it if you're not comfortable implementing that.)
If you still want to render the barcode with a font-based method, using Code 39 will be easier than Code 128 or Codabar. Code 39 does not have any check digits or a need to start and end with A, B, C, or D, with the tradeoff that Code 39 barcodes tend to be longer for the same data, and don't support as large a character set as Code 128 (though I've only ever seen this make a different with folks making barcodes with GS1 data).
You're asking about writing a script. The font-based approach philmodjunk describes doesn't use a script at all. You could make one of the plug-in based methods work without a script, too, but I don't recommend that. The plug-in and script-based products all make an image for you to store in a container field. That image file is a lot of data that is basically redundant with the primary key you already have, and I don't recommend keeping that kind of thing lying around. With any of the container-based methods, I usually recommend that folks only generate barcodes immediately before printing as part of a scripted process, and delete all the barcode images from the container fields after printing to save space.