I was recently involved in the implementation of electronic signatures (e-signatures) into the SAP procurement processes of a major auto company. When e-signatures were implemented into new purchasing documents, I noticed the need to extend this functionality to old active purchasing documents so that when they are changed or viewed, they can be printed or emailed with e-signatures. Current purchasing scenarios of major auto industries involve manual signatures (buyer needs to print, sign, and scan) in purchasing documents such as purchase orders, contracts, and scheduling agreements. Adding e-signatures functionality into purchasing documents benefits companies by saving time, meeting urgent business requirements, increasing security, archiving functionality of the documents, saving money on paper costs, and promoting a green environment. This article focuses on implementing e-signatures that append buyers’ signatures to purchasing documents when they are printed or emailed to vendors using Business Document Server (BDS) graphics and functionalities in SAP scripts and smart forms. This e-signature functionality fits into direct procurement, indirect procurement of purchasing scenarios, and purchasing documents such as purchase orders, contracts, and scheduling agreements. The following topics will help you in implementing e-signatures for your company:

• Functional requirements
• Technical requirements
• Storing signatures in BDS graphics
• Background processing of BDS graphics
• Signature repository maintenance
• Forms, image specification, and standardization
• Releasing documents
• Security considerations
• Additional features

This article is useful for procurement consultants, purchasing managers, business managers, and IT managers. Knowledge of procurement processes is needed to understand the content of this article. Knowledge of BDS graphics is also helpful.

Functional Requirements

When implementing e-signatures in your company, you should look into the following considerations. E-signatures should be stored in a secure place and should not be accessible by unauthorized users. Normally the master data entry team maintains this e-signature repository. The input screen to maintain the signatures should have Employee ID, E-Signature, and Validity Period, which looks similar to Figure 1. Buyers should scan their signature into an image file and email it to the data entry team. The data entry team crops the signatures as per the specifications and uploads them. Here the data entry team should have the option to upload new signatures, edit the existing signatures, and to delete them. These signatures are appended to Smart Forms and SAP scripts when they are printed, emailed, or faxed.

Technical Requirements

  To print signatures on forms, you store them in the system as a text or BDS graphic through transaction SE78 (Figure 2). Images can be uploaded as a Black and White Bitmap Image or Color Bitmap Image with required resolution and size. Uploaded images can be print previewed and deleted if needed.

Storing Signatures in BDS Graphics

You use transaction code OAC0 to maintain signature repositories. The contents are stored through transaction code OAC0 in table BDSCONT3 (Figure 3).     You can display details of the content repository (Figure 4) by double-clicking the field values or selecting the field value and clicking the details icon (the magnifier in Figure 3).       Storage requirements for the image into BDSCONT3 table have to be defined in terms of pixels, DPI, and width/height.

Background Processing of BDS Graphics

You should make use of the standard SAP functional modules in the functional group STXBITMAPS in transaction code SE80, for background processing of BDS graphics (Figure 5).       The following are the most useful functional modules used for background processing of BDS graphics:

• SAPSCRIPT_ATTRIB_GRAPHIC_BDS gets attributes of stored BDS documents.
• SAPSCRIPT_CONVERT_BITMAP_BDS converts bitmap to BDS documents.
• SAPSCRIPT_DELETE_GRAPHIC_BDS deletes BDS documents.
• SAPSCRIPT_GET_GRAPHIC_BDS gets BDS document content.
• SAPSCRIPT_IMPORT_GRAPHIC_BDS imports and stores documents to BDS.
• SAPSCRIPT_SEARCH_GRAPHIC_BDS searches for BDS documents.

Signature Repository Maintenance

As I noted earlier, the master data entry team maintains the signature repository in the system. Figure 6 shows a typical flow diagram for signature repository maintenance.   Users who change master data entries should have the following functionalities:

• Add new signature
• Change existing signature or validity period
• View signature
• Delete signature
• Mass upload of new signatures

You need to create a user-defined Z-table to contain the attributes of all signatories. Attributes include employee ID, validity period, deletion mark, BDS document ID, and change records. When a new signature is entered into the input screen, the system should perform the following actions:

• Validate the existence of signatory via the employee ID in the repository
• Transfer the image file to the internal table
• Convert the BDS
• Validate image attributes
• Store the image into BDS
• Store the attributes into a Z-table
• Change history into a Z-table

When any change request comes from the user, the system should be able to execute the validity period changes, replacing the current signatory image file and logging changes into the Z-table. When a deletion request comes from the user, the system should be able to delete the image from the BDS repository table, set the deletion mark in the record, and change history into the Z-table.

Forms, Image Specification, and Standardization

You should define attributes of the graphic in transaction SE78. The Name field should be set to Determine Dynamically. Determination of a BDS document can take place either directly in the form routine or through another program call within the SAP script. Set the Object as GRAPHICS and the ID as BMAP. Select the Determine Dynamically (BMON, BCOL) radio button and set the Resolution to 300 DPI (Figure 7). Technical specifications for images should be defined in terms of DPI, Height, and Width. The file type also should be defined (e.g., TIF file). Generally the buyer is given a standard form to sign to capture his signature. He should sign within the given box and with black pen only (Figure 8). He should then scan the form in black and white and submit it by email or directly to the data entry team. Once the data entry team receives the signature form, it should validate the signature as per the above specifications. Then it crops the image, saves it to the workstation as a black and white TIF file, and uploads it to the repository.

Releasing Documents

Often purchasing documents are subject to release strategies since they are external, legal documents. E-signatures should be appended to forms to print, email, or fax only after they are released. The function module should call the customized Z-program to append the signature only after documents are in released status.

Security Considerations

Since security considerations are playing a major role in any new project implementations, you should consider some important things. Images are stored through transaction code SE78. Users having access to transaction code SE78 can display, delete, or change the signature images. This transaction should be accessible to the data entry team only. It can also be controlled by the firefighter ID (FFID). BDS graphics should be stored as an “undefined” type to prevent the files from being accessible within transaction SE78. BDS graphics are client independent and therefore can be accessible for display within all the clients.

Additional Features

When you have gone live into your production system, you need to upload multiple signatures within the cutover time. You should develop a customized transaction to upload multiple signatures in a very short time. You can use batch data communication (BDC) programs for this purpose.