Skip to Content

Recently, my company embarked on an adventure of startlingly large proportions. We are a top-100 supplier to a number of large retailers and that put us in the bulls-eye of more than one RFID mandate. The mandates were to have their suppliers shipping product, with RFID tags attached, to a select few distribution centers in 2005. To be specific, we were required to apply an RFID-encoded label to each shipping container (case) for our product, as well as one for each pallet.

We decided last July that we were going to beat the mandate with or without another solution from SAP or anyone else. Our goal for the first phase of implementation was simply to print (commission) the RFID tags directly from SAP R/3 to an RFID printer and manually apply them to the individual product cases, as well as to the pallets. That seemed easy enough, until we realized how few people actually knew how the chips should be encoded and, even worse, how few people had actually done it. There was a happy ending to that phase of the project, which I will discuss later in this blog, but we were not finished!

That solution was working well enough at the time, but it wasn’t enough for us to realize any benefits — the magic ROI — in the supply chain. To do that, we needed to be able to read the RFID tags as they left the dock doors and tie that data into our backend R/3 system (4.6C). We also needed to tie in the tag read data we would receive from our customers so we could “see” the product all the way from our dock doors to the retail floor. That was far too big of a project to tackle on our own, so we turned to SAP and their AII solution. In March we implemented the “integrated scenario,” which included AII 2.1, and XI 3.0 as the middleware piece. That is the solution we are currently running, and plan to continue using (with the eventual version upgrades) into the foreseeable future.

My goal for the three parts of this weblog is to share with you how we got started printing the RFID tags with R/3 and take you up to our current process, where we are printing them using AII. My goal for this blog, Part I, is to provide you some background information on RFID and give you some insight on what needs to be printed on the RFID tags. In Part II, I will finish the example and hopefully put you in a position where you at least understand how to print RFID tags directly from SAP. If you are really curious, and have access to a Zebra R110XI+ RFID printer, you may be able to print RFID labels yourself! Even if you can’t get that far, it is also a useful exercise, I believe, in understanding what data gets encoded onto the RFID chips. In Part III, I will explain the set-up require to print the tags from AII as well as give you some documentation on error messages you may experience.

Terminology Definition

Before we get to the next part on encoding the RFID tags, you may have noticed that I have used the word “commission,” where I could have used the word “print,” and vice-versa when I am writing about producing the RFID tags. I call the process of producing an RFID label “printing,” because we use an RFID-enabled printer to print on the label and program the tag. In the AII world it is called “commissioning,” which denotes the reality that there is more to it than just printers. In AII he tag is logically created in the system and then sent to a “device” which is a logical representation of a printer or another device that is capable of programming the RFID chip. At my company we only use printers to create the tags so I use the term “print” quite a bit.

I also tend to mix and match the terms “tag” and “label.” I am referring to the same thing, of course, it is just two different ways I use to talk about the sticky label with the chip in it that gets slapped on the shipping container. The “tag” is the small chip with the attachment for the antenna and the “label” is the main section to which the tag is applied and where additional information gets printed.

In the next section, I will discuss what data goes onto the chip and what components make up that data.

Encoding the RFID Tags

The first question you may ask is, what actually gets encoded on the chip in the RFID tag? The real answer is anything that you can fit on it, but for supply chain purposes like ours, the EPC (Electronic Product Code) gets programmed onto the RFID chip by the printer, or another device capable of programming the RFID chip. The EPC is a unique code that identifies your company’s product to the rest of the world. EPC Global (the leading standards body for EPC’s) has a better definition than I could ever construct, so here it is: EPC Global FAQ’s. They also go into more detail on their EPC Global main page and they have the golden specification on exactly how the chips should be encoded with EPC’s for the various specifications here: (494 kb .pdf file): EPC Generation 1 Tag Data Standards.

So after reading those documents, you may ask “How did I pick which standard to use?” The answer to that question is not an easy one to answer, unfortunately. There are different flavors of RFID tags available, and different sub-sets of data page numbers and sizes that are available. That question is something that you would need to work out with your customer/supplier, using the established standards as your guide. There is also a good white-paper available from Symbol Technologies that describes the standards in more detail and explains the relationship between EPC and RFID.

Working with our customers, we started out using a 64-bit SGTIN (Serialized GTIN) tag, and have since moved on to the 96-bit SGTIN and 96-bit SSCC tags to satisfy our customers’ requirements. The code example in the next section will detail how you can convert an existing GTIN number into an 96-bit EPC code that can be encoded onto a chip. That is as far as I will go in this part of the weblog, I will save the fun part, the printing…er..commissioning of the tags for Part II. I will also save what you might need, and might not need, to print on the label for the next weblog. If you would like more information on what makes up a GTIN, try these web sites: GTIN Info, or GTIN Rules. For more information on the SSCC format, check out this small PDF file from the Uniform Code Council.

By the way, If you have AII 2.1 already, the R/3 AII add-on contains function modules that can decode the EPC numbers and do some other conversions for you as well, so the code example may only be an educational tool for you to see another way to break down the numbers. The added function modules in R/3 (with the AII add-on) are:

/AIN/EPC_CHECKDIGIT_CAL Check Digit Calculation
/AIN/EPC_DECODE Decoding EPC to Detailed Structure
/AIN/EPC_HEX_TO_CHAR Convert Hex EPC to Char EPC
/AIN/EPC_URI_TO_EPC Convert URI Format to EPC

AII 2.1 also contains those function modules, as well as an additional function to encode the values.

/AIN/EPC_ENCODE Encoding EPC detailed info to EPC binary

Specification for the Code Example

Before I get into the code specification, please be sure to review the guidelines I linked above from EPC Global first. They are the experts and I am just working with what they created to provide a reasonable example of how to work with the rules in SAP.

Now let’s get into defining the ABAP code that will allow you to convert a GTIN into the EPC data. This code will be set up to convert a 14-digit GTIN into a 96-bit EPC code, but it could be easily modified to work with 64-bit EPC codes as well, using this link above for the EPC specifications as a guide. In Part II of the weblog, I will extend the example to send the data to an RFID printer.

The printers we use allow one to send the EPC data in either ASCII or hexadecimal which, as you will see in part II, is specified on the command to write the data to the tag. As you probably noticed from the EPC standards, the limited amount of space on the RFID chips does not provide for clean character representation, or the nice 4-bit hex “words” that we all know and love. To work within that limitation, I decided to do everything in hex since ABAP seems to work well that way, using the “GET BIT” and “SET BIT” commands. The deconstruction of the EPC code below may convince you that hex is the way to go, or not. Either way, it works pretty well so that is the way we do it.

The EPC Global specifications require that we populate six fields to have a properly constructed 96-bit EPC code. In the EPC specification document it says five fields, but that may have just been a typo. There are six fields that need to be populated to construct the data correctly.

The first field is the header, and that is eight bits in length and is represented by a constant binary value of 0011 0000. The second field, the filter value, is more dynamic as it relates to the packaging type (single unit case, pallet, etc.) The specifications will give you more detail, and you will want to coordinate with your customer/supplier on what value you use. There is a reference table in the document that will shed more light on what values can be used but for the sake of this weblog I will be using the value of ’03’ — binary 011 — to represent a Single Shipping/Consumer Trade Item. We also use the value of ’04’ to represent the pallet. So up to this point we have 11 binary bits for the header and filter values: 0011 0000 011.

The next three bits, the partition value, set up a logical partition on the chip for the company prefix and for the item reference (material/article number). There are a total of 44 bits available for the two values, and the partition value sets up what number of bit values are used for each field. In our example, we are going to use seven hex digits for the company prefix (24 bits), so looking at table 7 of the EPC specifications, that means we need to use a partition value of 5, which will leave us with six hex digits (20 bits) for the material number (item reference). The three-bit binary representation of the partition value for this example ends up as 101, but again that is dynamic and may change based on your needs. The partition value of three bits plus the 44 bits for the company prefix and the item reference take us up to a total of 58 bits used, which includes the header and filter values from the previous paragraph.

The final 38 bits on the chip will be used for the serial number, which is for you to decide how to use. Just keeping track of (maybe in a database table?), and incrementing a counter for uniqueness would work fine.

For obvious reasons, I need to create a fictitious company reference and material number for corporate confidentiality reasons so if those numbers look a little goofy, that is why. For the seven digit company reference, I will be using 0012345, which I believe is significantly unique for the sake of an example exercise. The example material number is G19991 so the GTIN, which is a combination of the two, for this example is 00012345199912. I have no idea if that check-digit at the end of the GTIN is correct, that is just my guess.

The code example uses the partition value of 5 (binary 101) and a company code value of 0012345 (hex 00C0E4 – binary 0000 0000 1100 0000 1110 0100). The material number in the GTIN is 19991 (hex 004E17 – binary 0000 0100 1110 0001 0111). It is important to note that I am keeping track of the number of digits in hex, not in decimal. Hopefully that is not too confusing, but I am betting the code example will clear up any confusion that may have generated. Here is a table showing all of those values, and the serial number, in a little easier to read format:

Header Filter Partition Company Prefix Item Reference Serial Number
0011 0000 011 101 0000 0000 1100 0000 1110 0100 0000 0100 1110 0001 0111 00 0000 0000 0000 0000 0000 0000 0000 0000 0001

The result is a hexadecimal value of 307400C0E41385C000000001, which is the value to be encoded onto the RFID chip. The code example will show exactly how the encoding can take place within ABAP.

Code Example

Again, the code example will take the 14-digit GTIN number and encode it into a 96-bit SGTIN format that follows the EPC guidelines for RFID. The end result is the actual value that we will send to the RFID printer/device for it to write onto the chip.

Selection Screen & Main Processing

I set up the code old-school style, meaning I did not create a separate form to generically process each part of the EPC even though that would be very easy to do. I did it this way so you can step through it and easily see how the EPC code is created. In Part II, the function module that encodes the data with process each of the fields in a form generically, bit by bit in a more flexible fashion.

The parameters for the selection screen include the data necessary to create the EPC code that will be encoded on the chip. Then we’ll call the form to create the EPC code from the parameters, then the last form will simply display the hexadecimal EPC code on a plain output screen. If you want to see what the pallet label would look like instead of the case label, enter ’04’ for the filter value.

Encoding the GTIN into an EPC Code

The form below will take the parameters passed to it and use the set and get commands to set the bits correctly for the output string. All this is done in hexadecimal, only because I find it easier to debug the bit settings in hex. This snippet just includes the data definitions for the form, the other code is in the text areas below.

The code snippet below will set up the header value for the EPC code by looping through the eight bits, setting the correct bits on the EPC code. Since this value uses the nice four-bit “words,” we don’t have to use an offset here to get at the right bits.

Next, the code will set up the filter value for the EPC code by looping through the eight bits, setting the correct bits on the EPC code. This value is only three-bits, and in ABAP it is stored as a two-character hex field, so we have to use the +5 offset to get to the correct bits. The offset in the DO loop is the position offset within the EPC code to set bits four through six.

The rest of the code will set up the remaining fields using similar logic to what was used above.

Finishing Up

This form will simply display the hex EPC code on the screen. This will be replaced in part II with the section that will create and print the RFID label.

The Whole Code Enchillada
Here is all of the code in one text area.

As the end of the code shows, you will get the hex value of 307400C0E41385C000000000 if you execute it with the selection-screen defaults in place. Enjoy!

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Michal Krawczyk
    this is just great that even though
    this is such a new component we
    have such experienced people willing to share their knowledge:)

    thanks John:))

    keep going:)


    1. Former Member Post author
      we got the tags to print using a 3rd party printer which stored the printing format we wanted in memory… we had a RFC destination in AII defined and all print messaging occurred over that connection..

      1. Former Member Post author
        Thanks James!

        We are doing that as well, and I will blog about printing from AII in Part III.  I’ll include the fun error messages we have run into in that blog as well.  I think we hit ever single error possible at some point; hopefully that will be useful to you!

  2. Excellent way ,
    But I have one doubt about this, since I have created one RFID connector there I have used RW tags, I was able to fetch the record through device controller. when I tried to write on Tags through SAP, device managment was giving error.


    1. Former Member Post author
      Interesting.  I would be curious to know what device controller you are using since we were unsure if we could communicate to one directly from R/3 without using AII. 

      I should have been a little more clear, but I will be in Part II, that I will be sending the output to a printer that has been created in transaction SPAD.  I have not attempted communicating tags to a device controller from R/3.

      Could you talk about what device controller you are working with in the RFID Forum?  I would be very interested in hearing what you are working on!



  3. Mark Finnern
    Excellent post John, especially considering that it is your first one. Good background information and then right to the meat of it.

    Opening a new area for all of us SDNers.

    Thanks, Mark.


Leave a Reply