Skip to Content

I could sense the shift from panic to relief on the other end of the line.  “Don’t worry.  I’ll take care of it,” I repeated with a smile as I hung up.

It seemed like a straightforward fix.

After all, I had cleaned up other people’s messes before on dozens of SD output forms.  So a few totals were coming out wrong…  Not a problem – as long as I had enough information (and sufficient access) to reproduce the error I could trap and nail it.

Fortunately, the client already knew the name of the SAPscript form in question.  First step: get a brief form overview.  I dialed into their SAP system and scrolled through the form logic.  Among other things, I immediately noticed the long list of PERFORM commands – 17 of them; they seemed to be calling custom routines inserted directly into a standard SAP-delivered driver program.  Not good.  I wondered if the client knew.

I then ran a quick check on the form; the report showed 32 errors and 45 warnings.  Hmm.  With a sinking feeling, I verified the name of the ABAP driver program assigned to the form.  Yes, it was standard SAP code all right.  Instead of copying the code into a Z-version and remapping configuration to match – or placing the logic called  from the form into a separate program – the original developer had modified this program directly.  And once he had blazed a trail, others followed.  At least two other developers had made subsequent changes.  They seemed to have been in an awful hurry as well, based on the lack of internal comments.

OK.  This might take a bit longer than anticipated.  However, no sense in sounding the alarm yet.

I turned on the SAPscript debugger and reproduced the error, isolating the part of the form where the totals were wrong.  It led me to an ABAP routine being called by one of the myriad PERFORM commands.  I set a soft break-point inside this routine and soon found the ultimate source of the problem: the code was passing a value into an undersized field.  Ah-ha!

I logged into the Development box and compared the version there with the one in Production to make sure they were the same.  I made the appropriate changes, documented them, then dummied up some data and ran a few tests.  Finally, I informed the client that our fix was ready to go to QA for further testing.  Soon thereafter, an emergency transport brought the fix to Production.  Total time elapsed: less than 2 hours.

The client was pleased.   I was not.

Sure, this crisis was resolved quickly.  But how soon until the next one?  Was my task complete, or did I have a responsibility to pass along my larger concerns?

I had to say something.  At the same time, I needed to measure my response — unlike the overbearing auto mechanic in that Seinfeld episode who cares a bit too much about his customer’s car: “You know you wrote the wrong mileage down on the form? You barely know the car. You don’t know the mileage; you don’t know the tire pressure. When was the last time you even checked the washer fluid?”

On my own time, I carefully reviewed the form’s remaining deficiencies, ranked them by level of seriousness, and put together a game plan for solving them.  I then presented the findings, along with a recommendation for a full-blown audit of the other forms in their system.  Finally, I felt better.

Forms such as the one above are simply accidents waiting to happen.  Sometimes it is a mystery how they even work at all.  When compared with other programming languages such as ABAP, SAPscript code is less accessible and its error checking features less rigid.  As a result, serious problems in forms tend to fly below radar until they strike.  In addition, programmers generally are not – shall we say – overly enthused when asked to work on forms; the resulting level of detachment is evident.  Even worse, as output forms are a means of communication with your business partners, often they are the first ones to notice.  Take it from a (non-practicing) lawyer: As soon as one amount on a document is wrong, the rest of its figures get thrown into question.

How many such forms exist in your organization?  Do you know how much they are costing you?  The next time you draft an unwilling ABAPer to work on an output form, or have someone off-site (and unseen) do it, think about the results.  Other programming languages often follow strict coding standards and the code is subject to review; should output forms be any different?

Over the past several years, SAP has been moving away from SAPscript and toward newer form technologies such as Smart Forms and the upcoming Interactive Forms Solution Powered by Adobe (IFS).  As highlighted in my joint presentation with Matthias Zeller at last week’s annual ASUG Conference, IFS will support migration from Smart Forms, but not SAPscript.  As a result, knowing what is under the hood of your existing forms is becoming more critical.  According to research by SAP Labs, the average lifespan of an output form is 3 to 8 years; by now, it is possible that some companies’ forms have been on the road for a decade or longer.


Quick: What is the mileage on your forms?

This is part 2 of a series of Weblogs on SAP output forms.

To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply