Advanced Guide to SAP Compliance Labeling

 

Options for Generating Compliance Documents from SAP

As many of us who work with SAP know, there are many ways to accomplish the same task. Printing is one of those areas. Because of our AdvanceLabel for SAP solution, we are regularly asked about the various ways to print compliance labels within SAP and how they work.  If you’re just starting to look at how you’re going to address customer compliance labels, EDI-integrated SSCC labels, or if you’re looking for options for internal BarCode labels or documents, this guide should be helpful. To start with, we don’t believe there is a wrong way to print labels. Every environment is different, so we don’t presume to know what works in your specific industry or company. Our intent is simply to show you what your options are.

SAP Standard Message Output Technique

Most users are accustomed to output in SAP by using the message output technique. Message output uses a combination of condition types, access sequences and condition records to determine what to print and when. Message output functionality is attached to documents within SAP. In cases where there is no document, such as a relabeling effort, you could not use this technique. Message output is normally viewed from within the document, either under Output (SD) or Messages (MM), depending on the area of SAP you’re in. In the latest versions of SAP, an updated technique called PPF (Post Processing Framework) is also available.  

 

Fig. 1 Typical output conditions.

As shown above, most documents within SAP use the output determination technique to select output types that are pre-set in your system, and queue them to be printed based on established settings. In the case of a shipping label, this usually means adding a condition record for a handling unit to be generated when a delivery or another event, such as PGI, is created. An output can be created for almost any document within SAP (sales order, delivery, handling unit, shipment, invoice, etc.), although there are a few exceptions.  The output type in your document is just a pointer to a report program (see 1 in figure below). When a condition record is triggered, it points to and calls a report program where the real work is done. Depending on the setting in the report program, it will collect the data needed by the output and then generate the output selected, such as a printout, EDI, (IDOC), workflow, fax, etc. (see 2 in the figure below).

Fig. 2 How output condition records are processed.

This, as they say, is the meat and potatoes. To generate a label for a document, you need the report program to extract and make available the data that will be in the label/document, and a format that describes what it will look like when it is generated. If a label format is used, there are two types that SAP supports: older versions of SAP use SAPscript-based formats; SAP version 4.6 offers SmartForms, a new, more robust tool. Note that the addition of SmartForms does not stop you from using SAPscript. Both are viable options and, in some cases, you will use a mixture of each. (SAP has not converted old SAPscript documents to SmartForms, so both techniques continue to be used and supported.) I’ll describe them below. We do not delve into Adobe interactive forms within this guide, but that is also an option.

Print Methods

It’s important to note a characteristic that distinguishes what we call direct and indirect print methods. In the case of SAPscript or Smartforms, they are entirely managed within SAP and are direct print methods. The major benefits are that you can see full print job status within standard SAP print tools such as spool requests (SP01), and have print preview capabilities. In some cases, this is available within the originating application and also within the spool request.

 
Fig. 3 Spool output and print preview.

Using SAPscript-Generated Forms

SAPscript is a page markup language that SAP developed for use in describing forms. (SAPscript is not ABAP.) It’s simple to learn, but yet another language to add to your toolbox and for developers to worry about (Fig. 4.).  We recommend using SmartForms if you’re developing new forms.  The main reason for SAPscripts  continued use is the significant library of existing SAPscript forms available and the native support throughout SAP, whereas the newer technology has not yet been completely integrated. (Note that it is possible to make SmartForms available even within application areas that do not allow configuration options. Contact us for more information.)

Fig 4. Sample SAPscript.

Using the SAPscript language, the label/document and formats are described in a word processing format. Within SAPscript, each line of a label/document is described with placeholders for field data to be provided. As displayed in Fig. 4, each line can be preceded by a format, or each field placeholder can be surrounded by formatting that describes how the font/line is to be printed. BarCodes are handled the same way. In the case of the example below, the <LS> describes a BC character format for a Code 3 of 9 Barcode. What this means is that the field value is replaced on the document with a BarCode symbol.

Fig. 5 Sample Barcode symbol format.

SAP provides some of these fonts to be shown and used within SAP. The only caveat is that your printer must support printing BarCodes. Most LaserJet printers and clones do not, albeit you can add this capability using an attachment or software (see references below for guidance). SAP provides support for a limited set of Barcodes, but it is also possible to add additional capabilities with add-ons such as the BarCode.dll (see reference below). We do not recommend these solutions, as they require installation on SAP-application servers or printer servers (if they are separate), and installing any software on your app server is never a good idea.

In addition to using simple formatting as shown above, it’s also possible to use direct printing to a BarCode-specific printer such as a Zebra, SATO, Intermec, etc. To control these, it’s possible to send printer codes directly to the printer. This method, though more efficient, requires learning the printer-specific language. There are two ways to develop SAPscript forms for use on BarCode printers:

SAPscript Manual Method

This, as you can image, is the easiest to start with because you need nothing more than your working SAP system and time on your hands. This involves writing and formatting SAPscript markup text in the editor and configuring the use of your new label. The best practice is to take an existing form that SAP provides, save it as your own Z copy, and edit it to your liking. (We recommend starting with a SmartForm.) Though a graphical layout editor is available, it’s primitive at best and only helps with the layout of form sections (Windows) and is not a true WYSIWYG tool. The only real way to know what your document looks like is to test it with a real document. This can be a time-consuming process for a developer, as the process of writing SAPscript markup text and subsequent testing in an SAP document (delivery, sales orders, etc.) is required. A typical form can take a day or more to create and requires a developer,

SAPscript ITF Upload Method

A slightly easier method is what some companies refer to as the upload method. There are several third-party tools, in addition to Seagull Scientific’s BarTender (which we support), that provide this capability. Using a third-party tool, you can develop your label/document in a WYSIWYG environment, separate from SAP.  When the label is complete, the tool generates an ITF code. This code is then uploaded into your SAPscript form and can be used to generate the label as it was shown in the WYSIWYG tool.  Note that the code generated is a printer-specific code. Modifications can be made directly if you understand the code, but otherwise require a new cycle (tweak, extract, upload). Once it is uploaded to SAPscript, the external tool is not necessary unless a modification is required.  Several notes about this method: Though development seems simple, the user requires knowledge of the field names that will be made available by the report program that generates the label. The ITF file describes the label but still requires a report program to collect the data necessary to generate the label. SAPscript follows the change management process. Changes are typically made in a development environment, then transferred to a TST, then to a production environment. A typical label/document can take a couple of hours to develop but may require days to actually implement into production. This potentially can be performed by a business analyst with support by a developer.

Using SmartForm-Generated Forms

As of version 4.6c, SAP introduced the SmartForms tool to allow richer and easier development of forms. With SmartForms, there is no longer a need for external tools such as BAR-SIMM chips in non-BarCode printers, as BarCodes can be generated within SAP and sent to the printer as an image. The printer does not require the ability to generate BarCodes. This means that almost any printer can be used to generate BarCodes. (For performance reasons, you’ll still want to use BarCode printers for BarCode labels, but the ability to print BarCodes or graphics on any printer opens new opportunities.) SAP has also committed to supporting the Zebra printers and any printer that supports the ZPL printer language. So if you have a ZPL-based printer defined in SAP, it can be used in SmartForms without the need to add printer-specific language in your form. Though Smartforms seem to be easier to manage, it still requires development knowledge, as SmartForms are still called by a report program and utilize ABAP code within the forms to perform calculations or sophisticated rules implementation.

 

Compliance Labeling in SAP for Native Output

Without any additional tools, managing compliance documents requires the following steps when using native SAP tools and processes:

Using a customer’s specifications, a developer verifies and modifies an output report program to ensure all required fields are available.

The form is laid out using the SmartForms tool, adding fields that will be replaced inline when the form is generated. (The process is the same for a SAPscript-based form, but we would not recommend using a SAPscript-based form unless it is easier to modify an existing form then to create a new one from scratch.)

Using the SmartForm test tool, the developer periodically prints samples of the forms to verify the format. When complete, the form requires a condition record to identify the form to be printed. (This is typically what an end user will see in their document.)

When the form is complete, the standard change control process is followed to move the form and condition record configuration to a production environment.

 

 
Pros

-Native SAP form development using a gui-based tool.

-No additional tools necessary.

-Support ABAP language calculations and direct access to all systems data.

-Change control process ensures that forms are not modified accidentally and support requirements such as CFR 211 and EU GMP.

 
Cons

-Label development is not truly WYSIWYG. Only the form layout is shown.

– Form development realistically requires a developer for anything but the simplest forms.

-The need for a change control process increases the time it takes to deploy a document.

External Output Management (OMS)

External output management systems are intended for large, complex IT environments where managing printers in SAP is less then optimal. In environments where several main applications are in use, defining a printer several times in each system can become cumbersome and time consuming. In addition, when performing high-volume printing, SAP can suffer performance issues due to managing print output. Using an OMS, you can integrate an external print server to SAP. OMS systems are rarely used specifically for BarCode printing, but some OMS vendors provide this functionality, so we did not want to exclude mention. An OMS typically is sent raw data from SAP, and document formats are defined and managed within the OMS. One of the benefits of the OMS is that it looks at direct-printed documents within SAP, so usually there is visibility within spool management (SP01).  External output management, like an external-interfaced application, is ideal in high-volume printing environments.

 

Compliance Labeling Using an External Output Management Tool

OMS tools are intended to offload the print process from your SAP system, though some do allow form management.

Using a customer’s specifications, a developer verifies and modifies an output report program to ensure that all the required fields are available.

The form is laid out using the SmartForm tool, adding fields that will be replaced inline when the form is generated.  (The process is the same for a SAPscript-based form, but we would not recommend using a SAPscript-based form unless it is easier to modify an existing form then to create a new one from scratch.)

Using the SmartForm test tool, the developer periodically prints samples of the form to verify the format. When the form is complete, it requires a condition record to identify the form to be printed. (This is typically what an end user will see in their document.)

When the form is complete, the standard change control process is followed to move the form and condition record configuration to a production environment.

 
Pros

-Native SAP form development using a gui-based tool.

-Support ABAP language calculations and direct access to all systems data.

-Change control process ensures that forms are not modified accidentally and support requirements such as CFR 211 and EU GMP.

 
Cons

-Label development is not truly WYSIWYG. Only the form layout is shown.

– Form development realistically requires a developer for anything but the simplest forms.

-The need for a change control process increases the time it takes to deploy a document.

Best-of-Breed Print Application

This popular technique uses a best-of-breed application (such as our AdvanceLabel solution) as a central print method. Similar to external output management, forms are managed centrally in the external tool, which usually provides added features not available from a native SAP approach. In this indirect print method, SAP documents interface with the external application using one of the standard interface techniques (Filebased, RFC, Web Service, IDOC, etc.), which receives the data and then selects the appropriate label format.

Typically, the benefit of this solution is that the external application will provide a WYSIWG design tool to simplify the label design process with minimal or no changes to SAP. In cases where applications other than SAP require the ability to print labels or documents, this approach might be the best choice. This approach, like the external output management approach, is ideal in high-volume printing environments, as the print load is offloaded to an external print server and not the SAP application server.

 

 
Pros

-True WYSIWG design tools to simplify document creation.

-Change control process ensures that forms are not modified accidentally and support requirements such as CFR 211 and EU GMP.

-Connectivity and use by any application that can send output to a printer, file, web service, etc.

 
Cons

-External application to manage.

Conclusion

There are many options for printing compliance labels and documents in SAP, and no one solution will fit all environments. Advanced Solutions supports all of the methods described in this guide. We developed the best-of-breed AdvanceLabel solution to satisfy the most demanding compliance requirements with minimal operational impact. We can provide guidance for your specific needs or assist you in implementing any of the options we discussed here.

Below is a decision tree that can help you decide your path to managing a sophisticated printing environment.

For a PDF version of this guide select the link.

Pin It on Pinterest

Shares
Share This