Personal Insights
little SAPscript story
What output technology of a SAP ERP system exists now for more than 30 years? And has been repeatedly declared obsolete, antiquated and outdated? Right, I’m talking about SAPscript – the great-grandfather among the output technologies đ
Again and again I see SAPscript forms in the modules “Materials Management” and “Sales and Distribution” which are in use for a long time. Perhaps they will be in use for the next 10 years because they do what they should do: A proper preparation of business information to print, send by mail and so on.
At least that’s what they do most of the time. From time to time there are problems and this blog is about a little experience I made and that I want to share with you.
To simplify the maintenance of SAPscript forms, I have written the Open Source tool “SAPscript forms breakdown helper“. You can use it at design time to have a better understanding of the form. Advantages such as indentation, emphasis and so on make it easy to understand SAPscript instructions. Here is a little example:
It becomes difficult if you have a problem that can only be recognized at runtime. I had such a problem recently.
In a purchase order form, the delivery address sometimes corresponded to the address of the vendor instead of the address of the “real” recipient. The form was heavily adapted whereas the print program was standard.
Using the SAPscript debugger (see note 19104), I was able to identify the error in the CONSGNEE window. There was an individual determination of the delivery address by using the PERFORM statement with some values of SADR structure.
It was surprising that this logic worked in most test cases. Only in some cases not. After some analysis, it turned out that the structure SADR is used several times by the print program in different contexts. Therefore the structure contains different values at different times.
If the form is always processed the same way, that would be ok. Unfortunately, that’s not the case. As far as I remember, there is a note about the processing order of a form. But I couldn’t find this note anymore đ
The solution will probably be the return to the standard at this point. After reviewing the via PERFORM called form in ABAP, the individual address determination mimics logic that is now provided by the addition ADDRESSNUMBER of the SAPscript command ADDRESS. We will see.
What I learned from this little story? First of all: The behavior of the SAPscript debugger is hard to understand. Then of course: Do not rely blindly on the content of variables whose use has not been well proofed đ
Have a good time and thanks for reading
Michael
Top learning is: stay as far away from SAPScript as possible! đ Thankfully, in S/4HANA they will finally be gone forever, it seems. Good riddance.
Hi Jelena,
not sure about SAPScript no longer working with S/4HANA! As we still have many SAPScript forms, we looked into this and although earlier statements indicated that "the forms will still work but you won't be able to change them any longer" this no longer seems to apply for the version we've been looking at (1809). Or ist there any new information we may have missed?
I haven't checked on this recently but it was announced a few years ago in some SCN blog that in S/4HANA there will be:
I haven't heard about a change in this direction but I haven't been actively looking for this information, so it is possible SAP changed their mind since and didn't announce it as loudly.
Personally, I would love SAPScript to just burn. It should have been made obsolete ages ago.
According to fairly recent Note 2791338 "SAP S/4HANA output management supports SAPscript and Smart Forms for applications that used NAST before." AdobeDocument Services are however (obviously) recommended.
That's the same what I've heard. In the future, no new SAPscript forms should be created. I think the function will be deactivated. However, it should be possible to maintain existing forms. Otherwise, there would be a "big bang" for many users đ
OK, my bad. Thanks! Not the first time SAP announces something loudly but then backtracks based on the customer feedback. đ
For me, SAPscript is ok. It's a fine approach to prepare your business data for printing. But with SAPscript, it's a bit like in the days when you didn't have kernel and user space: there are many negative effects that are difficult to understand đ As I wrote: perhaps it will be in use for the next 10 years. From my experience, many SAP ERP customers want to replace the SAPscript forms, but they fear the costs. Especially because the technology change to SIFbA is initially not visible to the user.
Yes, unfortunately the maintenance cost is never calculated (at least not correctly) when there is an SAP team on staff.
In my old job, I was the only developer, so I my main goal became to reduce my own workload in the long term. When I had little time, I got rid of SAPScript whenever possible (like sales order forms), restored standard SAP output programs, consolidated similar forms, etc. But then when we had an implementation in a new company with a new language it was like "here you go, 3 forms translated in 30 min." Before that we had 5 forms for the purchase order alone!
SAPScript is incredibly expensive to maintain, in my opinion. But yeah, not many companies/managers/developers see that or care, probably.