In projects output play very vital role especially forms. Many documents like invoices, legal forms, shipping notifications, packing labels, etc. are printed out of SAP. Before printing a form we see print preview to check accuracy of content.
While seeing print preview we generally struggle to navigate across pages, problem in copying data from print preview or taking output into a PDF file.
To address these common issues we have some codes which can help in making our job easy. The below table explains code and its functionality.
Code
Description
P--
Display First page if multiple pages exist
P-
Display Previous page if exist
P+
Displays Next page if exist
P++
Shows Last Page
PDF!
Opens output in PDF-Preview
SGOT
Jump to page
SPRI
Print
SFAX
Fax
SEML
Mail
SARC
Archive
SARP
Print & archive
BKGR
Background
SEXI
Exit
SBAC
Back
SCAN
Cancel
SLIS
List display
These codes are called in Include LSTXBWFCC.
All codes will work for smartforms and sap scripts. Some codes like SFAX, SEML, SARC, BKGR work based on the way it is programmed.
Out of all the above PDF!, SGOT and SLIS are very helpful in my projects. I would like to explain only few of the above as most of the codes are self explanatory.
Output to PDF:
Taking output to PDF is a very common requirement below we will see how we can do this from print preview.
In the command box enter the code PDF! As shown below
When I first switched over to SAP for a profession, I spent a number of hours trying to figure out what and where functional teams were printing. We also a had a SAP implementation partner, unfortunately all of the Basis 'experienced' employees that came on board, the printing infrastructure had various printers and were not consistent through the landscape.
Since I have a background with Windows Server Administration and knew that within my company we have multiple print servers, I came across SAPSprint software and started preparing for printer changes. I also had no desire to log into multiple SAP systems to keep printers consistent and I'm not a fan of transporting printers, and then came across tx PAL.
So here is how I have printers setup using Windows print servers along with PAL:
I interviewed functional team leads to determine what document types need to be printed and which systems needed printing services (PI & BW for example in my setup do not require print outs)
Based on my requirements I needed Zebra printers (for labels), front end printers, spool only, check MICr printing, and only defined printers for nightly invoice batch printing.
As I was working on that process, a co-worker who still performs Windows administration suggested using DNS aliases on the print servers along with DNS host records for the printers so within SPAD it would have a line as follows for a Zebra: \\2300-01-PRNTSRV\L2300-01-101
Why do it like this, it allows for changes to only need to occur in DNS and SAP continues to work, think along the lines of loosing a main print server and your server team setting up a backup system for you to use.
Now because I am also the lead for SolMan, I know that it has RFCs to every system for other purposes, but by using PAL it can use the same RFCs. Now I recommend when you setup PAL to point it to client 000 on the target system; this allows you to also transfer device types through PAL. However device types seem to always require an open client, using 000 I have far less chance of someone modifying the system (also keep in mind that device types and printers are both client independent).
Now where things really paid off for me, I received an after hours call asking for a printer redirection due to toner being changed, and the users have sent about 15 - 20 documents to the printer. Now I don't need to tell anyone how much work for myself or the users this typically causes. But since I had things setup to the Windows print server I connected into that first and saw all of the 'missing' documents sitting on hold; I redirected the printer on this print server and all of the documents started printing.
So while it may take a little bit of work up front, in the long run its less overall management for the Basis team.
The standard configuration for SAP PP shop floor control output paperwork, accessed via IMG or OPK8, has not been changed to benefit from the introduction of Smartforms (ECC6 EHP 0). This restricts use to SapScript, which, although capable of providing the functionality to design your own outputs has some restrictions. One of the key restrictions we encountered was the requirement to have a printer capable of printing barcodes in order to add these to the outputs whereas with Smartforms you can print barcodes on any printer as it is sent as a graphic. That in addition to the fact that Smartforms are far easier to design and customise drove me to look for a way of configuring SAP to allow Smartforms.
The configuration of the production outputs requires the setting of a print program and a print form. In our system, and probably most others, the print program retrieves the print information from memory, retrieves the corresponding production order information and outputs it to the various sections of the SapScript form.
Solution
In order to avoid making any changes/enhancements to the standard SAP checks in config (OPK8) for SapScripts I chose to create my Smartform with the same name as the old SapScript form. This form name is retrieved in the print program (see later) and so taking this approach means that I don't have to hardcode the Smartform name in the print program. If in the future I want to switch to another Smartform I only need to change the config and if it is a completely new name I simply need to also create an empty SapScript form with the same name.
The new print program retrieves the print data in the same way as the old print program.
The code above brings back details of what production order to print, which document is to be printed (Production order, GR, GR label etc.) and which form is to be used for the output. The form name being passed is that set in OPK8 which in our case refers to the Smartform and also the dummy SapScript form. The print options being passed are as used for SapScripts rather than the format for the standard interface for Smartforms. Many of these have the same name so you can either move the corresponding fields to the Smartform interface and map the remaining ones, or, simply add structure ITCPO to the Smartform interface and then access the information in the Smartform from there.
The remaining processing that has to be done in the print program is to retrieve the function module for the Smartform and then call the Smartform.
The format of the form name being passed in the print information is that of a SapScript so it is necessary to save that to a local variable with the format of a Smartform name in order to be able to retrieve the function module for the Smartform.
lf_formname = print_co-forml.
Next get the Smartform function module name.
call function 'SSF_FUNCTION_MODULE_NAME' exporting formname = lf_formname * VARIANT = ' ' * DIRECT_CALL = ' ' importing fm_name = lf_fmname exceptions no_form = 1 no_function_module = 2 others = 3 . if sy-subrc <> 0. * MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO * WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. endif
In my code above I am simply passing the print options and print information to the Smartform and doing all the processing within the Smartform itself. I have done this so that I should be able to use the same print program to call Smartforms for all the production outputs although I haven't made that change yet.
Within the Smartform itself, the data for the production order is retrieved using the function modules below. The use of these was taken from the old print program and so that is the best place to start when developing your own Smartform.
Over the last few years, I have focused on Printing and Output Management as a topic within SAP Consulting. The starting point for that was the question as to how to print after a Unicode conversion has taken place; after conversion the documents will have different languages and code pages.
Until now, the answer involved four different alternatives:
A) Printing with Unicode Device Types (like HPUTF8)
In this case, SAP creates the print data without any font embedding. That means, the printer is responsible for including all the fonts required on its system (e.g. by adding them via DIMM chips).
B) SWINCF (Windows-based solution)
The second solution is to use SAPWIN as a technology. With SWINCF, the Windows system (either on the front-end or on the server) is responsible for adding the necessary subsets of fonts to the data stream.
C) External Conversion (e.g. by Output Management Systems)
Independently of the interface you are using (print data like PCL, pre-formatted data like SAPGOFU or raw data with RDI/UCPLAIN) this is an elegant way to print Unicode documents on every printer. There are several good conversion routines that are used by the standard output management systems like SAP Document Presentment by OpenText (StreamServe), LRS VPSX or others.
D) Printing with SAP Interactive Forms by Adobe
The ADS is able to render documents and do font subsetting out-of-the-box.
Each alternative has its own justification, but there was no direct solution by using the pure SAP standard. Each alternative has its own limitations (the most important ones in my eyes for our customer are: A: printer-dependency, B: relying on Windows for formatting and monitoring, C: not free of charge, D: need to convert to SAP IFbA means a lot of effort for existing SAPscript forms / Smart Forms).
Unicode Printing Enhancement (UPE)
Overview
In 2012, SAP started a development based on a co-operation with the German SAP User Group (DSAG). This Customer Engagement Initiative focused on solving this issue by developing a pure SAP solution.
The requirements for this development were:
Generic solution to print Unicode documents in the most common languages on PCL- and Postscript-based printers for ABAP Lists, SAPscript and SAP Smart Forms.
High level of compatibility and minimized influence on performance
Inclusion of internal PDF conversion
Embedding of only the characters that are needed in the print data stream (font sub-setting)
SAP will license fonts and deliver a holistic solution.
How to use UPE?
That was quite a bit of theory – but now let’s have a look how you can start with UPE. Assuming you fulfill the technical requirements (see Note 1812076), there is a new button available in the device configuration in transaction SPAD.
Yes – you enable UPE at printer level to ensure a non-disruptive change in your landscape. As soon as you activate UPE, you have to select a Unicode Reference Device Type (URDT) – for details check the chapter below.
If you do not print Chinese, Korean, Japanese or Taiwan, it doesn’t matter which URDT you choose.
After these two simple steps, your printer is now UPE-enabled as soon as you have saved the printer. You can check the available languages now with the button “Supported Languages”.
If your printer is using UPE, the following will happen: As soon as there is a character in the document that does not exist in the code page of the printer device type, the SAP spool will – by means of the URDT - extract precisely that part of the TrueType font and include it in the print data.
The big advantage in this case is the full functionality (using all of the languages) out-of-the-box by only adding the needed characters instead of a full font.
And if you convert your documents to PDF in SAP, the same methodology is used as described above.
No additional configuration is needed, as all of the fonts are included in SAP with the NW stacks mentioned in Note 1812076.
Unicode Reference Device Type (URDT)
For most of the languages the URDT has no effect. But if you want to print in Chinese, Korean, Japanese or Taiwanese, you have to take the following into consideration.
The URDT is not a real device type. Instead, it is more or less the flavor your output should look like. A simple rule (the CJK topic could cover a whole blog entry itself) is to choose the URDT for “your” country, e.g. the Chinese one for printers in China. All the non-CJK-Countries will be the same for all the different URDTs.
The real reason behind that differentiation is that Chinese, Taiwanese, Korean and Japanese share some code points in Unicode but use slightly different glyphs. In reality, a native Japanese would be able to read a text with a Chinese flavor, but he or she would recognize that a different character has been used.
With the support packages mentioned below, there is the needed integration in SPAD delivered as well as the fonts themselves and the addition to the internal PDF converter.
In addition to this standard scope, there is also a report delivered ‘RSPOUPE_URDT_TOOL’ that enables you to modify URDTs, e.g. to add an individual font or to customize the fonts used e.g. for list printing.
Availability
Starting with NW 7.40 SP03 and including downports up to NW 7.02 SAP will deliver this solution in the following Support Package Levels:
NW7.02 – SP14
NW7.30 – SP10
NW7.31 – SP09
Note: Kernel 721 is a requirement!
Details in Note 1812076.
Languages covered
To be very honest, not every language that is supported by Unicode (such as Mongolian) is supported by UPE. But here is a list of languages that are supported by this new solution:
So currently I am in the middle of the implementation phase for ERP 6.0. Currently we have three locations up and running, all locations have Canon printers and its been over six months without any output device specific issues.
This last Monday (July 15, 2013), I have the entire project team involved with a unit test coming after me...and I believe if it hadn't been in Mexico, they would of found pitch forks and torches. They reported that using any method F or G printer (leveraging SAPWIN and POST2 for device types); every document that was attempt to print using direct IP printing (no print server) the printer had garbled text on the first sheet and just spewed out blank pages.
So the first step we took was to setup a print server and have all the printers added to that and ensured we had the same driver as the other locations to ensure we didn't have a Windows driver issue. Functional members that were left out of the unit test helped with generating new prints and sent them to the print server to the printers and re-produced the same issue.
What I found interesting is that a Delivery note that I found in the spool had generated 1 page, on the Windows print server it shows 1 page, watching the Canon printer the print out exploded into 15 pages. Oddly enough the Windows print server is set to use a PCL5 driver for the Canon.
At this point I am baffled on what is wrong with the print outs.
I then start some back tracking with people involved with the deployment of the Canons. I now learn that when they went live with the printers they had issues printing from the AS/400 system that ran their business all due to PCL5 not being enabled/configured on the printer, and it would cost $11 per printer....Well if that was a HUGE mistake on someone's part for not ensuring that was setup during the installation.
So now I track down the tech who led the US Canon deployment who informs me that PostScript (which POST2 uses) has to also be enabled. So now with 5 days left prior to a go live, we have printers that won't print using POST2.
I also assumed those within my company will be slightly agitated if they are informed the go live is delayed due to the only printed documents that can be printed are on Zebra printers.
Now as a backup plan to support the go live I quickly whip up a method F printer in the unit testing system, find a PCL 5 device type and track down a functional person that can generate a new print for me to test on a Canon in HQ to verify that the document not only prints, but resembles what we are accustomed to viewing...and success!
Hopefully this can save time for future viewers who may run into something similar as this took me over 3.5 days to narrow down where & what the problem was, and always remember if the end user says they tested a print out; make them send the output to you (scan & email, fax, etc) and ensure they are following the business process vs thinking on their own and negating to report in a problem with printing.
A while back I lost access to my user account for SCN; this was due to a change of job which meant losing access to the ‘S’ user account I had registered with. Also one aspect of the new platform is that you can’t transfer/merge user accounts at the moment (and it will be “months” before this is possible). One of the first actions recommended for the new platform was to move your blogs to spaces, which is not possible for me. During the move to the new platform there was some damage to my blogs with a loss of images/formats and they are not in a state that I like and I can't update them.
So when the Barcode Writer in Pure Postscript (BWIPP) was updated a short time ago to include Kanji encoding, this was an obvious step for myself to update the Japanese SAP device type I had with the latest BWIPP version and post an update blog here on the new SCN. As my journey into the world of QRcodes/Barcodes began in Japan and I already had a version for a long time based on the Japanese SAP postscript device type, the actual QRcode Kanji encoding appealed to me for an update even though I have left Japan a long time ago. I also cover other aspects of using the BWIPP in this blog, including an ASCII85 (ASCII85 wikipedia entry) version and another section covering SAP server side setup.
When and if I get access to my original blogs I will remove this first section of the blog.
Most of the technical details I have used can still be found in my original blogs here.
In my original development of the SAP barcode device types based on the BWIPP it was suggested to use the BWIPP ASCII85 encoded versions. The ASCII85 BWIPP versions can be foundhere.
I do like the ASCII85 encodingmethod as it reduces the amount of code and therefore the size of the SAP device type. The number of "action pages" in the device type is reduced from 5 to 2 for the QRcode version.
The new device type also contains two extra print controls to cover some extra formatting options for smartforms. The first SDN blog covers printing to text files first to determine the correct print controls, the comments section to that blog also cover these new print controls.
*Reducing the number of SAP Action pages required for the device type.
*Reducing the size of the device type
*The extra print controls covering Smart Form formatting.
New device type print controls
In most "normal" formatting of smartforms then new print controls are not required, however if no barcode is displayed then the format of the postscript generated from the smarform needs to be checked as described below.
There is a section in my first SDN blog about "Identify the Text for the Barcode" so if I quote the relevant section below.
"Standard formatted text can appear with the "s" command however sometimes especially if small text formatting is used other postscript procedures such as "w1" and "w2" appear. So any new form or output that requires a barcode should be output to a flat file. This is to check the file for the postscript formatting and commands used by SAP. This can be useful to note where to insert postscript commands via print controls (also for any trouble shooting). A tip for smartforms and sapscript is to search for lines with "<~" and "~>" as this signals ASCII85 encoded text. "
As the smartform will be converted to postscript then the way the smartforms text format is converted is vital to allow the barcode to be printed.
a) So lets start by creating a Windows frontend printer that prints purely text. This will be used to create a text file of the SAP generated postscript.
Follow this note but use the QRcode/barcode device type Note 576973 - Creating a file printer on a Windows PC
b) send the smartform to the new frontend printer. You will be prompted for a file location so enter c:\smart.ps for example (the full path must be entered).
For example in the following screen shot I have used various formats in a smartform and I sent the output to the file printer on my desktop.
c) open smart.ps and search for "/s {bct exch ctxt" which is the start of print control ZBW01. (Note I have added the "= testing .... " text myself for this blog to match the above smartform screenshot.)
In the above smartform output shown in the red box, there is some formatting to do with the width/size of the text so the normal postscript s command is not used and therefore the qrcode would not be generated correctly.
*NOTE, in the above example the formats in the postscript use w1 and w2 as an example, the exact formatting may be different in your smartform.
The postscript commands w1 and w2 are used instead of the S command in the smartform. Therefore to keep the formatting in the smartform we can use the two new print controls.
The TWO new print CONTROLS are. ZBW90 = /w1 {bct} def /w2 {ctxt /bct exch def} def \n ZBW91 = /w1 {SW 0 8#040} def /w2 {widthshow} def \n
d) Change the smartform to include the new print controls
..TEXT - empty / or blank lines to make room for the barcode ..PRINT CONTROL ZBW90 ..TEXT FOR BARCODE ..PRINT CONTROL ZBW02 ..PRINT CONTROL ZBW91
Basically the ZBW90 changes the W1 and W2 commands to allow the concatenation of the text. ZBW02 is the same command to generate the QR code. ZBW91 resets the W1 and W2 to SAP standard postscript.
e) Print the smartform to the original QRcode(barcode) printer with the new print controls and the QRcode should now appear in the output.
The following extract is from the Barcode Writer in Pure Postscript page detailing all the supported barcodes. Using the same method any of these could be incorporated into an SAP device type. If you see any you would want to use in SAP then you could follow the original SDN blog to create your own.
The BWIPP supports an impressive list of barcodes, as listed here from the BWIPP site.
The project supports all major barcode symbologies including:
The BWIPP can now encode Kanji into the actual QRcode, so a combined ASCII85 and BWIPP updated version can be found in the zip file for the Japanese device type download above. The link again here. In the subdirectory "japan kanji" device type ZJPSPTQK, can be uploaded and I have updated the ABAP code (ZQR_PRINT2KAN) with kanji for a demonstration as shown below.
The ABAP code now as Kanji in the line that generates the QRcode, as per the following screenshot.
This version merges the BWIPP on the SAP server side. Therefore there is no need to configure PDF software or use scripts to introduce the BWIPP to generate barcodes. Server side integration allows the possibility to print direct to a postscript printer.
By using standard SAP configuration the BWIPP can be merged into the SAP output stream on the server side. Therefore reducing any configuration on the client side by placing the configuration on any SAP application server used for printing.
Also as the solution is purely postscript based ANY postscript 2 compatible printer can be used for a barcode solution. While I no longer have access to any HP printers, I did cover this at a previous location and posted elsewhere in regards to printing postscript on HP printers.
Display the Text Objects and IDs, search your Object, you want to change. This is what you see ( It's just an example, so don't be surprised by not finding the same names)
As in my blogs before I’m a fan of the counting things. Today I want to share my experience in an area I’m a heavy user. I develop a lot of forms in my career as an ABAPer and I also worked through a lot of it. Unfortunaly I also see a lot of things, which make a form very hard to understand and out of that, form-programming is one of the things a lot of developers do not like that much.
In my case, I’m very into it, because I like the output in the end. Sometimes I get a paper in my hand, I developed before and now I’m one of the “aimed” which the company wants to provide information.
Ok, there are also some, I do not love to get in my hand, bills and stuff like thatImage may be NSFW. Clik here to view.
Back to the topic, what I wanted to say before is, that forms doesn’t have to be complicated and difficult to debug if you follow some rules and with this blog I want to share some of the main rules you should really set a focus at.
I’m not saying that there is for every special case a solution in, but I’m absolutely convinced that 95 percent will be getting easier to handle by one of the guidelines here.
First point: Give your smartform a name, which is readable
This is an easy point to archive, but why are names out there, nobody can understand. I mean, is it really necessary to name a form WLF_INVLI01? You got enough letters left, to provide a readable easy to find name to your form... I think there are the 2KB left on the disk
2nd point: Name your nodes, use the description field
Another easy enemy to fight. I know it is always a messie work to go through the tree and give everything a name. But be sure, as in another blog I published, your work will return one time and be sure, a form will return a lot earlier than the restImage may be NSFW. Clik here to view.
You will love the minutes, you invested in this point.
Add folders as much as you can, it is a fantastic thing to get a clear view in your form, it makes the life a lot easier and you will find the correct spots to enhance something a lot faster than before
Everybody who ever developed a form came once to the point thinking about saving a coding for later. Customer called, say something is to replace and you, as a developer, know right in that moment, this coding returns and you do not want to trash the output before. There are two ways to fight a thing like that: First is you save your form with all data, you just download it or create a copy in the system. That works most of the times not that good, because it is just a little spot you want to save for further developing. That’s the point I refer to point three again, if you use folders you can deactivate it by adding a condition 0 = 1 (you know, code inspector do not like 1 = 2 that muchImage may be NSFW. Clik here to view.) and give a clue to it.
5th point: Create easy Conditions if you really need some
Most of the conditions in a form I see are really not necessary. It would be a lot easier if the content would be passed to the form in way, it is printed. But if you really need to develop conditions, create easy conditions. Do not double your conditions, just because you need to hide two or more fields at once… again point three cross our streetImage may be NSFW. Clik here to view.
We all know, it is a really easy thing in a smartform to add some values to an output. Developers might know sentences like “Add me additional customer-number right at that place.” Doesn’t take long, am I right? Yeah, but that is a returning thing in a way, nobody wants to face. It is fast and easy to create a coding-node in the depth of your smartform, but does your younger colleague next to you find it again. Or better, do you remember that node in three month again? Exact that is the point, you dig a grave and waste a lot of time in future, just because you save right now 15 to 30 minutes to do it in a good way.
Right before we talked about creating the nodes and now I’m saying do not use it at all? Are you crazy? No, I’m not (at least I think thatImage may be NSFW. Clik here to view.) and why I’m adding this as an extra point. I’m adding this as an extra point, because there are a lot of disadvantages. You know, the editor in the smartform itself is a joke, isn’t it? Not big, hard to read and if you write a few lines, you aren’t able to see everything. You have to add every import and export parameter extra and if you delete or rename one, you can easily waste 20 minutes with searching your form. Why don’t do things like that in your driver program. Big editor with all advantages, don’t have to say anything more here, do I?
It is all stuff which could be passed to the interface as well or at least done in one coding-node.
8th point: Name your global and local variables in a good way
As mentioned in my intro, I work through a lot of forms and I’m always asking me, why people think, that a form is not restricted by the guidelines at all? Every developing is related to the guidelines, name conventions and stuff like that, globals start with GV_, locals with LV_ but having a look into a form brings names like SF_ which might be stand for smartform( if you found the transaction code I think you know where you are) or even things like nothing before…
I can just say, take a look in your guidelines and use the guidelines also here, just because it is a generated coding and it doesn’t look like developing a program it is Coding and so your guidelines take also care of this part of the project.
9th point: SELECT from database is not a good solution at all!
It doesn’t matter in what context you are working, but I see a lot of SELECTS in the form-programming and I ask me every time the same question. Why do people think, that a form does not also get a count on the performance side. I mean, nobody would just program select without thinking twice in order confirmation or price-routines. But in a form it doesn’t matter? I know, nobody is perfect, sometimes it has to be fast and however you didn’t recognize it afterwards and it’s gone. Just a example, there is a form with 30 SELECT-Statements in there, whoever work through all of that to see if it is required? Yeah, we all know the answer. There are a lot of companies out there and earn their money with performance-tuning. Here we got an easy way to bring our part in. But you have to remember it during you develop it. Spend now 20 minutes longer will save you in the future hours of refactoring and junk searching through junk forms. I know that feeling very wellImage may be NSFW. Clik here to view.
And here it is my major point. Most of the other points hit in that direction. Use the interface. If you do not know why, just go to point one again and start reading againImage may be NSFW. Clik here to view.
Thank you for reading to the end. I know, smartforms and all the form stuff aren’t that popular, but you know, in the end of each project and each single step in every company there is an invoice.
Feel free to add additional points or leave me a comment. I'm very interested to learn something new everyday, as you perhaps know.
Cheers
Florian
BTW: Most of the points are also the same if you use Adobe-Forms. It is the mass of javascript to avoid thereImage may be NSFW. Clik here to view.
If you want to print a bar code, you have various options:
1. Printing via bar code DIMM/SIMM or barcode-capable printer
To be able to use this method, the printer itself must be able to print bar codes. Therefore, it must be possible to access the bar code via a simple escape sequence. Frequently, you require a special bar code module for the printer.
The printing works as follows: SAP sends a simple printer escape sequence that activates the bar code, then the bar code text in plaintext and finally a sequence that switches the printer back to normal printing. In this way, therefore, the lines of the bar code are created by the printer itself (see Note 5196).
Whether bar code printing is supported in this way can be seen from the note that the printer manufacturer created within the Printer Vendor program. Note 1097990 contains an overview of these notes.
- Supported documents: Sapscript, Smart Forms, (lists) - Supported bar codes: All bar codes that are implemented in the printer/bar code module - Supported printers/device types: All printers that are barcode-capable - Display in print preview/PDF file supported: no
2. Printing via a barcode.dll
If the printer cannot set the lines of the bar code itself, this must occur elsewhere. One option is that you print via a Windows system, device type SAPWIN and a barcode.dll. If you print via SAPWIN, the print formatting occurs in the Windows operating system. This then uses the barcode.dll to create a graphic that contains the lines of the bar code (see Note 14561). Note 14561 contains various suppliers from whom you can obtain a barcode.dll.
Supported documents: Sapscript, Smart Forms, (lists) Supported bar codes: All bar codes that are contained in the barcode.dll Supported printers/device types: Only SAPWIN device types Display in print preview/PDF file supported: no
3. New bar code technology
If you do not want to use or cannot use the first two methods, you can use the new bar code technology that is described in Notes 430887 and 645158. In this way, SAP creates a graphic that contains the lines of the bar code. SAP then prints this graphic. To be able to use this option, you must use transaction SE73 (system bar codes) to create a new system bar code because the SAP standard bar codes normally use the old technology (option 1 or 2).
Supported documents: SAPscript, if you have implemented Note 1558595, Smartforms Supported bar codes: Code39, Code93, Interleaved 2of5, Code128, PDF417, data matrix Supported printers/device types: PCL device types, PostScript device types, Prescribe device types, ZPL-II device types, SAPWIN device types (see Note 430887) Display in print preview/PDF file supported: yes
4. Using a bar code font
There are Windows TTF fonts that contain bar codes. You can upload such a font to SAP and use it by calling transaction SE73 and choosing 'Install True Type Font'. For more information, see Note 201307.
Supported documents: SAPscript, Smart Forms Supported bar codes: Various 1D bar codes Supported printers/device types: Most PCL device types, PostScript device types, ZPL-II device types, SAPWIN device types (see Note 201307) Display in print preview/PDF file supported: Yes
5. Printing via a PDF-based form
The Adobe Document Services (ADS) creates the lines of the bar code here.
Supported documents: PDF-based forms Supported bar codes: Various 1D bar codes and 2D bar codes; see selection in the Adobe Designer. Supported printers/device types: PCL device types, PostScript device types, ZPL device types (see Note 685571); for SAPWIN device types and Prescribe device types, see Note 1066060. Display in print preview/PDF file supported: Yes
All the printer vendor and manufactures who have developed their device type can apply for the certification by contacting us icc-info@sap.com
Why certify my printer device type?
SAP’s mission has always been to increase customer satisfaction with high quality solutions and innovations. Hence, the focus is to increase product quality and accelerating customer value. SAP Integration and Certification Center (SAP ICC) continuously works on enhancing its portfolio, the result is the certification offering for printer device types. By certifying your printer device type from SAP ICC you not only add value to your device type, but also help you to reach more customers through marketing support such as ‘SAP® Certified Printer Solution’ logo and listing your device type under the SAP Online directory.
Developing device types under SAP Printer Vendor Program does not automatically qualify the device type as certified and tested by SAP. Once the device types is developed successfully under printer vendor program you can contact SAP Integration and Certification Center for certification.
What do I need to prepare before I apply for the certification?
- Your device types development & self-testing needs to be done in SAP printer vendor program development system
- Your device type is ready for general release and a set of relevant documentation has been made available for SAP customers to use
To get an overview and understanding about the SAP Printer Vendor program click here.
How many device types can I certify in one single agreement?
Maximum of five device types can be certified within single agreement. Once the certification agreement has been signed with SAP ICC, a technical consultant from SAP ICC will contact you to kick-off the process. In order to ensure a timely start, make sure to submit your certification request as early as possible since the processing of your request is not instantaneous given the volume of partners.
What are the scope and requirements for certification?
- Focus of the certification to test the device types with printer model from SAP system. It is necessary to verify the operability of those setups by testing them.
- The certification tests the device type feature on specific printer model from interaction level.
- Printer vendor provide list of device types names to be certified along with the details of printer model on which the testing can be performed.
- Custom-tailored test plan that best suits your device type has been defined by ICC.
- Certification will be conducted onsite where printer model and SAP test system is available. Onsite location can be either SAP office or partner office based on facilities available in order to incorporate the testing requirement.
- You have set up the system landscape for testing of your device types:
- Printer model on which testing is to be performed is usually provided by the partner
As every device type is unique and distinct in itself, the testing and validation is also specific to each. Therefore, it is essential to discuss your device type features with an ICC consultant as early on as possible to allow the consultant to evaluate it correctly and define a custom-tailored test plan that is specifically catered to the device type. If we consider the certification in abstraction from its specific criteria, this process is relatively straightforward. It is worth highlighting that in most cases, its duration, complexity and success are determined by the partner’s level of readiness.
Benefits of Certification:
- SAP Certificate
- Test report
- SAP certification logo “SAP Certified Printer Solution” which you can use for marketing your device types
Below are some of the quotes provided by our certified partners.
Toshiba TEC decided to certify the printer device type to prove the quality of our solution. The certification from SAP ICC will definitely add value to our solution and will help us to reach out to more customers. The certification process was very smooth right from receiving the certification contract and completing the certification testing. We also believe that this certification help us in promoting the reliability of our printing products to SAP customers’- Masateru Mitani Software Engineer, Toshiba TEC Corporation
The certification from SAP ICC will help our customers to understand that our printers have good compatibility with SAP. The certification testing also helped me to notice some of the settings which was difficult to use. Going forward customers will ensure to buy certified device type as it verify the printers quality.- Satoshi Watanabe, Engineer of printer software, Fuji Xerox Co., Ltd.
As we can see under the Corbu theme of SAPGUI, icons are displayed larger and brighter than other theme, but when printing, the old icons(themes other than Corbu) will be printed instead.
This is because that the Corbu theme is simply applied at SAPGUI level, when creating spools there has no difference in Raw/OTF data as other themes, so either the print or convert the spool to PDF, icons will be outputted as their default view.
We can take a simple test by using report RSTXICON.
> Create spool No. 123 within Corbu theme. Create spool No. 456 within Signature theme. > Change back to Corbu theme and see these two spools in in SP01, both of these look the same, icons are displayed as Corbu. > Display Raw data of these two spools, we can see nothing is different.
So if you want to print the icons as they appears in Corbu Theme, Instead of the Printing(Ctrl+P) we have to use the 'Hard Copy'(Alt+F12+H), it will capture the current screen and send the picture to your frontend printer directly.
Today’s blog is the first of a series in Output Management. I really thought a long time about what to focus here and finally I found it.
So now, some of you might think: “What he’s talking about?” – I’m talking about developing a driver program from the very beginning with all the necessary steps between.
There are some blogs available at the moment and I want to draw the whole picture, so that everyone is able to start from the beginning and hopefully got a good developed driver program and also a good Sapscript/Smartforms/Adobe in the end.
A guide how to handle the process from the request to the final form.
What to do before getting your hands on your keyboard and what not to forget when having the hands on there
30% is developing with the hands on the keyboard, what are the other 70%?
What do you expect from your output?
This blog will focus on the different techniques and what are the advantages and disadvantages, all from my very personal point. I will also share my lessons learned and perhaps it helps some to avoid some pitfalls. This blog complete the first part of the process.
How to begin – What are the different sources and what is a good basis to start with?
Where to look for proper/preconfigured programs/forms and how I decide if I take it or leave it in the end.
Interfaces in forms – What to do and what not to do?
There are a lot of mistakes out there or people believe how things work. Because it is showing the correct value doesn't mean that it is a good solution. I don't want to tell more right now.
How to enhance my own programs – Enhance the interface?
This blog will focus on the interface itself and how to make your life easier when the program returns to you. I’m not sure at the moment if it gets an own blog or if I include it in the Interface in forms blog… I will see at the moment I’m writing it.
What to do before getting your hands on your keyboard and what not to forget when having the hands on there
The headline says the complete blog in on sentence. You got different techniques to develop an output for your customer / company (or whatever you are developing for).
That means in the beginning you have to translate all the necessary things from the business.
Until this point there is no difference between developing and if you follow a previous recommendation of mine
But, forms are most of the times not in the direct focus. The reason might be that all people focus on the system and the doing inside it.
Easy example, business is thinking about having new pricing things, everybody focus on the calculation view and if everything is managed correct. Often the form is passed out and in the end there is a ticket for meImage may be NSFW. Clik here to view.
But that is not everything you have to think about. I made myself a decision-card which I use a couple weeks right now.
It doesn't contain the whole picture I think, but if you take care about these points (ok, here is my counting againImage may be NSFW. Clik here to view.) I’m pretty sure you can speed up your developing or if you are doing it in a similar way you are able to add something useful to it.
Ten questions I ask always in the beginning:
1st What techniques are available in this system?
If Adobe is available try to use it. It is the state-of-the-art technique and you are very flexible with it.
2nd Are there other forms already developed?
I always try to match the “mainstream” in a system. All forms developed with Sapscript and no need to change to another technique out of the business requirement I stay with Sapscript.
3rd Is a corporate design necessary?
Normally there is one in a company. You need to take care about it in any case, if there is no hard-written book available take your time to check other forms and have a look at it. It ends in a lot of wasted time when you are just designing things by your own. It is just like music, not everyone likes hard rock.
4th Is a layout-proposal offered?
Nice if you have one, but most of the times it just contains less information, because the business cannot imagine the output in the end (at least all the different variants). So it is very important to call the responsible persons from time to time and discuss the next steps.
5th Do you need special information on the form?
That question is not that clear, what I mean is if it is necessary to print a datamatrix / barcode or if the form is planned to put in the next machine afterwards (automatic mail-machine for invoices for example).
6th What about future requirements?
Any plans to enhance the today-build program? I let all the stuff explain to me and decide within the future requirements. It doesn't help you and your business just because of saving one or two days of developing today, if that mean you need a lot more time in future to maintain or to enhance the form.
7th What kind of device-types are installed?
Different types mean different behavior and so I have to know before starting with my work. There a lot of OSS-Notes out there, for example this one: 90437 Generic device types do have less space between letters. That is very important to know before designing the layout.
8th How many people using the form in the end and how much printouts are expected?
This is a very important question too, this let me decide how I handle my data. Example: Business wants a delivery number printed. The select need to pass 5 tables before it is available. This information helps me to redesign the process and not let my driver-program fetch the information leaving every performance behind. Sometimes this leads to a complete other developing for me too.
9th Translation needed?
Answered with yes, what is the default and if already forms there how is the translation managed? (This is another story to tell, because there is another way next to the SE63 available, a custom-made way, but in my opinion with a lot advantages)
10th Are you pretty sure about the nine questions before?
The most important question at all. Make sure you write down all the answers and summarize it in a document and give it back to the business. Everybody involved should have a copy of it (also the guys of the marketing division).
In any way keep always in mind that another developer should be able to answer all the given questions with this document. It always helps to sent it before to another developer and ask for feedback.
That’s it, this is the first part of my blog series and I hope you enjoyed reading it.
Feel free to leave a comment and/or give your opinion to this topic.
this blog will focus on the different techniques and what are the advantages and disadvantages, all from my very personal point.
Now, where is a good start to begin? This is very specific point; it depends on how deep you are into developing forms. I start here with the three basic descriptions and afterwards I show a decision-table (a very personal one).
What are the three different techniques? (a very small part of history included)
is the oldest way to create an output. It has some limitations and out of this reason it isn’t used that much right now. I know a lot people saying that this way to create output is horrible, but I do not agree at all. Yeah, it might be a hard fight to have dynamic boxes and to insert a dynamic picture is really hard to manage. Yes, that’s true, but on the other hand, it has a genius concept behind, is very easy to understand and you get your data on the paper in less than 5 minutes if necessary.
Why I’m saying that, because the entire introduction always starts with what you see is what you get and that is in my opinion nearly everywhere NOT true. I mean, if you do not have just hard coded values without any dynamic flow on the paper it might be true (but in that case it would be easier to go for Sapscript). Anyway, I do not want to take the given opportunities away. Smartforms is based on an interface and that is a big + to it. With Smartforms it is possible to have one form reused in a very easy way if you know how to use an interface. But that was another story and I already published it here
This is today the state of the art technique to deliver forms. In release 6.40, SAP introduced Adobe forms and this was a major step for all the form-developers. It uses also an interface and additional to that, as the name already tells it has an own IDE developed by Adobe. This IDE contains everything you ever used before in Word / Openoffice or whatever you are addicted to. IFbA has a lot of good stuff for you. For example you can save the data of the output and use it in your testenviroment to develop the form. You can easily include graphics from a server and a lot of different fonts/barcodes/qr-codes are native supported. On the other hand, you leave your ABAP-world just after entering the designer. No ABAP here, just Formcalc and Javascript. You need to have some prerequisites (for example you need to have an Adobe document stack running on your system and you have less chance to debug in an easy way.
Also here a lot of people are talking about the WYSIWYG, but my mind also did not change here.
Enough of talking about the techniques itself and let us continue with the decision table. This table doesn't contain all the different cases and of course it has a very personal note.
What would(should) I use?
What is the requirement?
SAPScript
SmartForms
Adobe
Complex drawing of lines and boxes (static and dynamic)
No
This is a messy work and take a lot of time
Yes, you got a good support
Absolutely yes!
Label printing
Yes, just depends how complex it is
Yes
Yes, but it will take some time to understand the concept
Graphics without converting or SE78-uploads (BMP, JPEG, GIF, PNG, EXIF)
No
No
Yes
A lot of different TrueType fonts using in one font
(not Helve and CourierImage may be NSFW. Clik here to view.)
Yes, but not recommended
Yes, but not recommended
Yes
Systembarcodes (that means you do not need a barcode-module
Yes, also here, have a look at SAP-OSS 1558595
Yes
Yes
Interactive scenarios
No, not possible at all
No, not possible at all
Yes (who would have thoughtImage may be NSFW. Clik here to view.)
Colored Fonts
No, not possible without using the backdoor
Yes
Yes
How fast can I find a mistake?
fast
Fast to slow, it really depends on the delivered quality
Fast, but you might end in trouble when you love to code inside your form
What do you need to know
ABAP
ABAP
ABAP + JavaScript / FormCalc, at least you need one of the additional
Conclusion
Now you may say, why don't always use Adobe. Here is my answer: Adobe is always to prefer, but you also need to see, how much it takes to develop the form. If you have a preconfigured program given by the SAP or you adopt an old one made with sapscript or Smartforms (not the good ones) you might get in trouble to move everything to Adobe. So what I want to say is that you need to decide if there is a quality shifting doing it with Adobe again, especially if you are not that familiar with Javascript/Formcalc and the given workbench of Adobe. I suggest that it offers more than 1000 Buttons and you will never know them all Image may be NSFW. Clik here to view.
Hope I could give an insight in the different techniques and may help you with the next decision.
As always, feel free to leave a comment, add something I could insert in the decisiontable and/or give your opinion to this topic.
Cheers
Florian
PS: I really do not know an official Logo of Sapscript. Maybe someone can anwer the question if there is one.
PPS: Next time I do the counting thing again. It doesn't feel like me without having some bullet points includedImage may be NSFW. Clik here to view.
it can happen that you are running a 64Bit Operating system, with a 32 Bit SAPLOGON, in this case the 32 Bit version oft he SAPPDFPRINT is to be installed
This topic is a really tricky part and I thought a long time how to describe the process. I hope you can get something valuable for you out of it.
How to begin – What are the different sources and what is a good basis to start with?
As I promised in my previous blog I’m back at the counting thing here. Before doing that, I talk a bit about my personal experience in this area.
The major problem all of us are facing remains nearly everywhere the same when starting with new things. There is no place, where it is all nicely described and prepared in a way, you could find it quick. That’s why everybody of us has a personal wiki. This is a good thing, but everybody needs to go through the lessons learned section and that is for sure not so good.
SCN and a lot of community member made it happen that there are a lot of good sources out there. These sources are not included in this blog. In my opinion there is an easy way to go: Official sources first - SCN second and last but not least the InternetImage may be NSFW. Clik here to view.. This statement I always use, because unfortunately there is also a lot of not good content out there (it is the polite form I would have said here).
So now, back to the basic question of this blog:
Where to look for proper/preconfigured programs/formsand how I decide if I take it or leave it in the end.
Yeah, it is really that easy. Have a look into your system and look for the customizing. Often there are some dummy-entries made with the correct driver-program/form and you just need to grab it from here
2nd Market Place – OSS-Notes
Now you should have a look here. Best keywords are your transaction-code (also the description is a good choice) and the technique you prefer (SapScript / Smartforms / Adobe). PS: You should not got for SAPScript todayImage may be NSFW. Clik here to view.
3rd Best Practice Packages offered by SAP
This offers you a great source of preconfigured forms. Major problem is most that it isn't that hard to start without anything, but I cannot recommend you that. There are a lot of pitfalls during the form development and this is a very good source to avoid a lot of it, not all, but a lot. Here is the link: http://help.sap.com/bestpractices
4th Search the community
Here on SCN in the wiki are a lot of knowledge conserved. Most of the times you won't find a ready to run program, but the basic pieces are most of the time available. For example what kind of class should you use or even you find the correct program delivered by SAP. PS: I started a site, which focus on forms and there I’m building a table with the common Adobe-Forms + Programs.
What is developed in the form, how does it work, what kind of data is used by now
2nd Examples examples examples
I know, but it is that important, perhaps more important than everywhere else. To archive the first point you need a lot of examples and all the different cases which need to be covered by the form
3rd Show the business
Show the form and all its functionality to the business. Don't do it by your own, let someone (who is comfortable with the process) do it, if it is too technical the business will not intentional to the message you want to tell them.
4th Ask about the layout twice
What? Yeah, you read right, Ask a second time about the layout. I recommend to publish the layout in a bigger meeting (ask before you do that) and show it to other people so that the whole team can say something about it. You won't be the first, which need to rework the complete set again, because someone missed to know about the corporate design in his/her company.
After doing the above there is just one thing left to do before starting. This is my personal card, I have learned over the years that form developing is producing a lot of wasted time, because change request nearly never includes the output.
I have made me a “Do remember”-card for this. This could be part of the technical documentation, but make sure you publish it in your team and everybody knows how to search for it (Project-Wiki / Quick-Search) without wasting time.
I know, this is a very common statement, but in my next blogs I will try to describe how I think this could work goodImage may be NSFW. Clik here to view.
To remember
Answer (just Examples)
What processes use the form?
Sales-Process (Offers / Sale-Contracts)
What T-codes using it?
VA** ( BA00 / AN00 / AF00 )
Who created the form?
Florian Henninger / John Doe
Any special logic which will be hard coded?
BUKRS = 1000 à Add additional text (Clue of Owner)
MATGR = 253 included à Print additional ADR-Paper
Main-tables (if not that well known)
VBAPB / YSD_VKGRP / YSD_BRANDING
Passed out things (excluded by the business)
Subcontracting
Others
…
That’s it, this is the third part of my blog series and I hope you enjoyed reading it. Now we can talk about the other 30% of the developing process. Some of this part are right now included, because it can't be separated that hard, but that's why it is called processImage may be NSFW. Clik here to view.
The next blog will focus on Interfaces in forms – What to do and what not to do?
PS: The pictures are collected by somewhere from the internet. So if anybody knows that there is a copyright protection please let me know and I will remove it immediately.
This blog focuses on using the open source project Barcode Writer in PostScript (BWIPP), also translated to JavaScript, with SAP and is based on PostScript device types and JavaScript services. The BWIPP covers all major barcode symbologies ( including QRcodes, DataMatrix, Aztec Code and many more).
I originally covered the method to use the BWIPP with SAP in 2010. Last year the postscript version was updated to produce 2d barcodes with an optimum size. This lead me to update the QR code device type and other barcode types I originally blogged about in 2010. Also as the BWIPP project has offered a translated JavaScript version for a while, I took the opportunity to try and use this version with SAP as well.
Summary
I will split my blog into three parts. The first section will cover the update to the PostScript device types, the next two sections will show ways to incorporate the JavaScript versions with Node.js and then using PhantomJS with the ICM hosted JavaScript code.
Originally I had created some Unix scripts to adapt the BWIPP code so it could be included with SAP device types. I updated the scripts to use the ASCII85 packaged versions of the BWIPP project. I was able to extract the relevant barcodes to copy and paste the code into the device types. Therefore I have a method to create any of the barcodes into SAP device types. QRcode, Data Matrix and Aztec Code device types can be downloaded by following this link. The download file also includes the other example smartforms and JavaScript code that I cover later in this blog. In the main directory of the zip file the device types are as follows ZBWPQR3.PRI, ZBWPAZ3.PRI and ZBWPDM3.PRI. These need to be allocated to an output device as outlined in this blog.
Since the original blog in 2010, I have either replied to blog comments or direct emails about certain requirements people wanted for Smart Forms in particular. These comments and emails also confirming the process worked from SAP version 4.6c up to the latest versions.
An example QRcode based smartform can be downloaded via the same zip file link in the the root directory - called z_qrcode_bwipp.xml . If you follow the original blogs method to create an output device and linked to the new Device Types then the smartform can be printed directly to PDF (or direct to any PostScript enabled printer).
The smartform is standalone and will work if tested via the generated function module. The Smart Form was created on a trial version of SAP 7.02.
Test (hit the test icon in the following screens and you will be prompted to select a printer, the one created with the device type ZBWPQR3 should be used). The generated function module is enough to run the Smart Form as it is self contained.
The Smart Form is an example and only a test of the print controls that have been added to the device type. Take a look at the smart form for the various ways the QRcode is manipulated.
Server side update
Updating to the latest version of the BWIPP to be used server side as per the blog post
To update the BWIPP using the server side method is a simple case of swapping out the one file which contains the BWIPP. I have tested the following version from the following download page (which will include the optimum sized 2d barcodes).
I extracted the barcode.PS script and replaced the Dbwipp from the original blog post. A copy of the updated Dbwipp in the serverside directory of the download.
An example smartform that can show 26 barcodes on one page. The example Smart Form is called z_26barcode.xml again in the serverside directory of the zip file above.
The bwip-js project has translated the BWIPP PostScript code to native JavaScript. Also it has been made available as a Node.js npm package. I have been using OpenShift (using the free applications running on their PAAS) with other applications so I thought I would try out the BWIPJS node npm version. OpenShift makes various “cartridges” available to run and Node.js is one. So I have deployed the bwip npm as one of my free OpenShift applications. This was based on the demo Node.js application from OpenShift which I adapted to include the demo code from the bwip npm page.
Example barcodes below generated by my OpenShift barcode web service I have running. (if outside images are allowed at your site a QRcode and Aztec Code should be shown below -
I came across this document http://scn.sap.com/docs/DOC-47644 that is based on a Google service to generate QRcodes. I did doubt my cut and paste skills with my own 7.02 SAP NSP trial edition as the code did not activate without making some minor changes to the code. However once activated it worked fine and a great idea. I would recommend running the BWIPJS service on an internal Node.js server and not a cloud service. However this is just a demo and my site will not be around forever. I will leave it running though as long as I can, if the live images above are not shown then that indicates my OpenShift application is not running.
I swapped out the following line that uses the Google service from the above linked SCN document.
Then to get an Aztec Code simple change the bcid parameter to the following. (Therefore any of the supported barcodes in the BWIPjs application can be used.)
The following method is also based on the blog More Barcodes with Barcode Writer in Pure Postscript by calling external commands to generate images. This time using phantom.js to create an image that can be used in smartforms. This is just an example to see if it would work. As the JavaScript version relies on the canvas of a browser, I needed Phantom.js to be able to covert the code into a usable image for the Smart Form.
I had previously followed the blog linked below to serve up sapui5 with the ICM, I used openui5 in its place
One option for me to do is to use the bwip-js directly with openui5. However for my Smart Form tests I used my adapted bwipjs code to generate a QRcode image with Phantom.js.
The example code I used to generate an image can be found in the zip file download above, under the directory Javascript\smartform. I then adapted some bsp code I had created and covered here (changed the imagemagick and ghostscript commands to the phantom.js script found in the Javascript\smartform directory in the download). The way I cropped the image with Phantom.js is covered in this stackoverflow question and answer. My adaption was to adjust the offsets to get the barcodes into the final position. The rasterizecrop.js script in the download directory is based on the stackoverflow answer and the batch file zbwipjs.bat was created and called via an external command with transaction sm69 to control the process. I have not included the exe for Phantom.js as that needs to be installed from the Phantom.js site. There is a batch file called barcodeimage.bat in the download file that does not require SAP or any web server to generate the image. As long as Phantomjs.exe is in the executable PATH of your system the code should generate an image as per below.
SAPPDFPrint is used for printing PDF spool requests using front-end printing (access method G) or SAPSprint (access method S). PDFPrint is therefore installed on your local PC with method G, or is installed on your Windows SAPSprint print server when printing with method S.
The patch level of SAPPDFPrint you use is dependent on the SAPGUI patch level or the SAPSprint patch level. So when you print with method G, SAPPDFPrint needs to use the same bit version as your SAPGUI (32-bit) and also use a compatible patch level. In general it is recommended to use the latest patch version available of both SAPGUI and PDFPrint together.
Similarly, when printing through SAPSprint, SAPPDFPrint needs to use the same bit version as your SAPSprint (32 or 64-bit) and also use a compatible patch level. In general it is recommended to use the latest patch version available of both SAPSprint and PDFPrint together.
Related SAP Notes:
1444342 - Device type-independent printing of ADS forms 1490835 - Patches for PDFPRINT
1783811 - Improved version check of PDFPRINT
1822381 - Assignment version info patch level SAPSprint/SAPFprint 730
1909193 - 64-bit versions for SAPSprint and SAPPDFPRINT
