11

We need to parse the GS1 datamatrix barcode which will be provided by other party. We know they are going to use GTIN(01), lot number(10), Expiration date(17), serial number (21). The problems is that barcode reader output a string, the format is like this 01076123456789001710050310AC3453G321455777. Since there is not separator and both serial number and lot number are variable length according to GS1 standard, we have trouble to identify segments. My understanding is that it seems like the best way to parse is to embed the parser in the scanning device, not from the application. But we didn't plan an embed software yet. How can I implement the parser? Any suggestions?

Terry Burton
  • 2,801
  • 1
  • 29
  • 41
BackToSorrento
  • 119
  • 1
  • 1
  • 4

2 Answers2

7

There should be a FNC1 character at the end of a variable-length field; so that FNC1 will appear between the G3 and the 21.

FNC1 is invisible to humans but can be detected by scanners and should be reproduced in the string reported by the scanner as the GS character (ASCII value 29). Simply send the string directly to a text file and examine the text with a hex reader. The GS character representing the barcode's FNC1 separator should be obvious.

If you can, it might be an idea to swap the sequence of the 21 field and the 10 field since you appear to be using a pure-numeric for 21. This would make the barcode produced a little shorter.

Terry Burton
  • 2,801
  • 1
  • 29
  • 41
Magoo
  • 77,302
  • 8
  • 62
  • 84
  • 1
    I tested 02034531200000111709112510ABCD12343710, there supposed to be a separator between 10ABCD1234 and 3710. I used ASCII encoding, and get the bytes of the string, ASCIIEncoding.GetBytes(barcodeString), it only read 38 bytes, the FNC1 is still missing in the byte stream. – BackToSorrento Aug 21 '14 at 18:18
  • The absence of the FNC1 indicates one of many things. It could be that it's missing from the label, or the scanner isn't sending it or that the software you are using isn't processing it correctly. What I would do is to take a known-good FNC1-containing barcode from the EAN manuals (I don't care what their name is this week, it's not relevant.) Try reading that code into something like *notepad* which should show the extra character (can't test, equipment not to hand). You could also try a routine which accepts raw bytes and displays hex - even read into `cmd` and create a file which will have – Magoo Aug 21 '14 at 20:07
  • a length. If you can detect that FNC1 from EAN source by one of these methods, then that indicates the reader is OK, if not, suspect the reader. If you can find the FNC1 in EAN's code but not in yours, then suspect the label-production software or equipment. If one of these simple methods can find FNC1s and you are convinced the label is correct, then suspect your (presumably) C# routine. – Magoo Aug 21 '14 at 20:12
  • Thanks, Magoo. That was good suggestion. I will keep you updated. – BackToSorrento Aug 22 '14 at 14:42
  • 1
    The code I tested was from the GS1 manual, the FNC1 is visible from my iphone scanner. So I have very good reason to suspect the device. We decided to discuss investment on a more sophisticated device. – BackToSorrento Aug 22 '14 at 14:54
  • "There should be a FNC1 character at the end of a variable-length field that is not filled to maximum." The requirement for FNC1 is irrespective of whether a field is filled. The FNC1 should be applied to any "variable-length", non-terminal field. (Variable-length is a bit of a misnomer: Strictly speaking the GS1 General Specifications implicitly define a list of AIs not requiring FNC1 by listing all field that *do* require them and stating that all future definitions will also require them.) – Terry Burton Sep 21 '16 at 14:36
2

One way to deal with this is to program the scanner to replace FNC1 with space or another plain text character before sending it to your application. The scanner manufacturer usually provides a tool to produce programming bar codes that can do simple substitutions in the scanner. Then you can parse the data without having to handle special characters.

joeforker
  • 40,459
  • 37
  • 151
  • 246
  • 1
    The transmission protocol strictly defines that FNC1 (other than in first or second character position) must be transmitted as a GS character (ASCII value 29). So a typical substitution would be to translate GS characters to something that isn't valid in GS1 AI values such as `~`. – Terry Burton Mar 11 '23 at 21:02