Moving to S/4 – What about your output management?
it took me a while to finish this blog here because of a lot discussions why and moreover how to handle it. Anyway, that is just a sidenotice and I really appriciate your point of view. So leave a comment and tell me your point of view to this topic. If you just want to dive into the technical recommendations start with point custom code adaption
As you might have already read in the simplification list, SAP has made a strong commit to IfbA (Interactive Forms by Adobe). Fact is, that Sapscript will be no longer officially be available to customize your output.
Find below a example snippet out of the simplification documentation 1511
126.96.36.199 Billing Document Output Management
With SAP S/4HANA a new output management approach is in place. By design, the new output management includes cloud qualities such as extensibility enablement, multi tenancy enablement and modification free configuration. Therefore the complete configuration differs from the configuration that is used when output management is based on NAST. The configuration is based on BRF+ which is accessible for customers. In SAP S/4 HANA, the target architecture is based on Adobe Document Server and Adobe Forms only. for the form determination rules(along with other output parameters) BRF+ functionality is used( in this sense in combination with the message determination).
Output management based on NAST is not available for new documents in SD billing. Billing documents that are migrated from legacy systems and for which NAST based output has been determined, can be processed with this technology. For all new billing documents the new output management is used. Therefore in Sales & Distribution are billing/customer invoice there is a need to adapt the configuration settings related to Output management.
It is recommended to use Adobe Forms but due to a compatibility the form technologies know from Business Suite(like Smart forms, Sap Script) are supported as well. Other channels are not available by default.
Here is the direct link:
Additional to that there are more than this part which aims to the output management. You can common information under Top Cross Application – point 188.8.131.52Output Management
For me the important snippet is:
Print Technology: The SAP S/4HANA Output Management supports the following print technologies:
o Adobe Forms
o Adobe Forms using Fragments
I have read a lot content about preparing your landscape (especially ABAP) for the big move. For example
– Get rid of old (not used) code
– Check the health-state of your system
– Analyze Select-Statements and so on.
A nice summary of necessary steps can be found here. Thomas did a great job and this blog has opened the way for the blog you are reading at the moment.
ABAP custom code adaption for SAP HANA – The efficient way
What always is not mentioned, Output-Management… 😐
So the question I have in my mind: How to prepare the forms for the future without having this major invest on the point of upgrading! Next to the money it is hard to name a timeline on that and that is a risk for the whole team.
Great thing is, that Thomas filled my gap how to present this blog here and so do not wonder, I borrowed the headlines:-)
Ok, enough of my motivation and see what we can do.
Preparation phase before the migration (old system landscape)
Overview and Planning
One of the most important points whatever you do with your system is to have an overview. You need to identify every single form you are running in your system and you also need to know what these are doing. I see a lot systems and one of the common problem is, that there is no overview what forms are used and moreover which process is it calling. I don’t talk about the common forms like sales order or billing documents, these forms everybody can name when I ask the first time. The black box are label-forms or the internal paper which might look ugly but is a process-accelerator for your internal employee.
So the message is, invest some time (and of course in a way money) to get an list of all forms and what process are calling it.
After having the overview you need to identify how to start. That’s an easy task, because again the well known forms are normally also the forms, which need a lot of time to analyze and prepare for the upgrade. So you just need to decide which form will be the first.
Out of the part of my motivation there is at the end only one possible scenario in my eyes. Develop all forms with IfbA.
Hint: The process how to technically process with it remains always the same. That mean, if it might be helpful to start with a “not-so-complex” form to get used to it;-)
Adobe Document Stack
There are some sideconditions to use IfbA. This blog do not focus on that, so here is a link how to configure it.
Configuring Adobe Document Services for Form Processing (ABAP) – Adobe Document Services for Form Processing – SAP Libra…
The only aspect I want to cover, is that you don’t need to install the ADS (Adobe Document Stack) at your landscape if you do not want. There is a offer from SAP to run it as a service. You can find some information about it here:
SAP Forms as a Service by Adobe
and the cool thing, that is why I mention it here
There is a free trial! Find the necessary information in this blog:
Form Service by Adobe: How to try out
Developing Forms with IfbA
Additional to that, this blog also do not cover it, how to use the IfbA tools and how to develop forms. There is a lot information available and I just link the two official courses here. Anyway, I think if you made it to this point of the blog you have at least some experience in developing forms.
Most of the tips in this blog remains the same also for IfbA
custom code adaption
Driver programs from SAP are a good point to start, but most of the times it doesn’t cover all the aspects you need. That means in the end it is better to have a own copy based on the original program than having a lot of modifications or implicit enhancements.
Another quote from the simplification list
As the new output management is an additional tool there should be no direct influence on custom code expected.
That means you can carry on like those developers 😆
Ok, I’m willing to believe it, if you are using the standard SAP driver programs without enhancing these with own logic, but who doesn’t need some custom fields at the output?
In the end every single company has in a way some forms which are sent to customers, partners or suppliers. Every system has somewhere the need to add some custom fields for specific information during the project and this need also is chained with the need to bring some of this stored information on the paper.
So now, if you are not one of the lucky ones that never used “Appends” on database tables will for sure have some homework to do to also make your form work again under S/4.
Let us start with an simplified (love the wording) example and afterwards let’s see how to decouple the information.
A very simple example to transport the idea
Customer- Contains the customer information (yes, for real:-))
Bookings – Contains the to be printed bookings ( positions )
Both tables have an append which store specific information. Right now the developed driver program reads the information and pass it in the same defined dictionary structures.
The problem right now is, that under S/4 a lot of tables will be dropped and replaced with views.
That means, that you need to also invest some time into your existing IfbA-Form.
So here are my recommendations how to handle it:
Decouple the interface-structures from the tables. In our example develop an own structure for the header-information and one for the positions. SAP also develops all the forms with this technique.
Of course you can and you should use the SAP-formbased structures, but you should add an (Y)Z-structure for your own fields, so you are able to release the binding to the appends.
See below the recommended structures:
So here you can see, that the information now is really decoupled and no matter what, the form itself is absolutely prepared to be used under every system, no matter if it is called S/4 or ERP Classic. It just depends on where the information comes from and having nothing programmed inside the interface to fetch necessary information does underline the need of a copy of the driver program.
During the migration (new system landscape)
You have nothing more to do with your form itself, you just need to do the customizing.
After the migration (productive system is live on SAP HANA)
You just can focus on your new possibilities with S/4 and don’t need to waste time with repairing the output-forms.
A few questions still there?
Yes, also for me.
What about Sapscript and Smartforms at all.
For example you use Smartforms to create HTML-Content or you use it with webdynpro?
Do we need to add it to our worklist long- or shortterm?
Feel free to leave a comment or to add your personal statements about your experience. What way do you use to handle it?
BTW: All used pictures belong to their copyright-owner.
Thomas mentioned this OSS http://service.sap.com/sap/support/notes/2228611 as an additonal source how to handle it and thank you for the headlines 😛
Great blog, Florian, and a very "hot" subject.
I believe SAPScript is work of the devil and should've been sunsetted long time ago. 🙂 But... One of our ECC systems was setup around 2009 and it's stuffed with custom SAPScripts. Many of those are rather important forms (such as customer account statements, QM reports, shop floor packet for manufacturing, etc.) and it'd take quite a bit of effort to re-do them.
Obvious question: why SAPScripts were still used in 2009? Obvious answer: despite banging the Adobe drum for years, SAP actually did very little to revamp the output and deliver standard print programs and forms for many essential processes. Or if they did something they forgot to tell the customers.
This migration could have started years ago and the customers would be in a better shape now. Right now, based on what you're saying, I foresee we (and other customers) are looking at the heaps of complete "do-overs" with translations to multiple languages. That's quite a bit of work...
As you noted, it's very important to know and organize your outputs and forms. I built a list as soon as I started working here and have been adding to it since. It's been tremendously helpful on many occasions. Also it allowed us to identify that we were using 4 different forms for essentially the same output (got rid of 3 of them eventually). This is the effort that can be easily started today. Don't wait till the last minute.
This "I foresee we (and other customers) are looking at the heaps of complete "do-overs" with translations to multiple languages" is probably one of the reasons SAP feels there is no need to refactor their own applications as the new output management tech gets added.
I may be too cynical, but the claim in note 2228611 that the "new output management replaces all legacy frameworks" - I'll believe it when I see it. For example, it would be a considerable effort for SAP itself to redo FI-CA and IS-U Correspondences, the underlying PWB Form infrastructure and the related printing Mass Activities.
And all that effort to gain what... better "low energy" E-mail output and XML Ariba integration? Freedom from ABAPers? Separate logos or footer texts per company? Multiple messages to multiple recipients using multiple of 3 channels at the same time? More features for which the customers, if there was a need, one way or the other had probably found a way of supporting them? Call me underwhelmed.
Mass Activities at least have FI-CA Job Commander to schedule and run them - to organize your mass output, to put some kind of EMMA/BPEM monitoring on it. Not much info on mass processing in the "new style", but I guess EMMA/BPEM monitoring should be possible (there are SLG1 logs).
As for the central customizing activity...
I wonder who thought that was a good idea. 😕
The old stuff is not really going to go away, I think, yet again... It's just another reason to declare dead-end (sorry, legacy) something that got promoted to cross-application stuff (PWB and Correspondences in this case) and to likely stop developing features for it. To summarize first impression: yet more tech to master for those having to make it all run! Sad! 🙂
My thoughts exactly. I even typed in a response to that effect but decided not to post after all because no one would reply anyway and it'll just go against my SAP complaint allowance. 🙂
We've been hearing about the inevitable rule of Adobe forms for at least 10 years already. It seems super convenient that the new note only mentions vague "future".
thanks for this blog! I have one additional question: is there a difference between the different deployment options: cloud, onPremise, managed cloud?
I read above mentioned OSS notes as well as additional notes and I note statements that are not precise and raise questions. F.E.: "new Output Management Framework replaces FI-CA Print Workbench". There ist no print workbench in FI-CA, Print Workbench as well as the Correspondence Tool are in SAP_ABA. There is an extension of the Correspondence Tool in FI-CA that uses Print Workbench as well as the Correspondence Tool. But the message from the note is clear: All current print framworks became obsolete. So your advice from decoupling Business logic is valuable.
In fact I did the same in my output management projects and tried keep ABAP code in Application Forms of Print Workbench small instead of doing the standard implementation where much coding is done in the user exits.
I don't think that there is a difference between the options because everything is designed with the BRF+ Framework under S/4 as far as I can see. Would you expect a difference between the options?
after reading all notes I agree with you: the architecture is quite the same and all output will be sent to a printer that can be anywhere. So Cloud and onPremise architecture should be similar.
Is there a document describing the implementation of the new Output Management? Especially the migration from Application Forms could be challenging. As I described above I tried to avoid them in my projects but I know from many industries that they use sometimes very sophisticated tricks (f.e. prefetching Business data in the SAP Banking Solution for dealing with high volume scenarios.
And I have another questions:
some important questions also for me. Right now I'm diging for the answers on multiple channels. Right now I'm waiting for response. I let you know.
Please do not confuse BRF+ and output management.
BRF+ is the replacement for the condition technique in NAST and only part of output management. Output management itself is not implemented in BRF+ but mainly as a business object using the BOPF framework.
thanks for the hint. Haven't read it from that perspective... Are you also attending Teched this year? Would be nice to talk to you in person about it.
Technically the onPremise and cloud editions share the same codeline but of course there are differences when it comes to what a cloud user can actually do. For example you can configure the system to use existing SAPScript, SmartForms and Adobe Forms in the cloud but you will not be able to change such forms without backend access as the corresponding editing tools are not cloud enabled.
So for the cloud it is a must to move to the new Adobe Forms.
For onPremise this also recommended but optional.
Interactive Forms are currently not supported.
Preview and editing before printing is in principle possible with the new output control, but the business application decides if and how it is available.
Thank you for taking time out to write this blog.
Very important topic
A very useful information. This has been one of the areas which is a difficult for any customer looking to move to S/4 HANA and the information shared will definitely help lot of folks.
Thanks for sharing the info.
More information on the S/4HANA Output Control can be found in the following SAP notes:
2228611 Output Management in S/4 HANA
2292571 SAP S/4 HANA output control - technical setup
2292539 SAP S/4 HANA output control - configuration
2292646 SAP S/4 HANA output control - form templates with fragments
2292681 SAP S/4 HANA output control - form master templates
2294198 SAP S/4 HANA output control - customized forms
In the new style, in relation to legacy forms, what "format" of spool requests is expected and what is a "document"? 🙂
(Hyperlink to facilitate the access to the notes: 2228611 - Output Management in SAP S/4HANA -> this note itself contains the links to the other notes)
Thanks for this nice blog.
I would like to know more about supported channels. Is it possible to configure any other channel, say for example Fax?
thanks for the interesting blog.
Do you know if FI module is also influenced by the decision not to support SAPScript anymore? In FI it's still quite common to print dunning letters, account statements, etc. by SAPScript technology.
SAP has moved the FI-Forms a while ago to Adobe. So as written above my recommandation is to use Adobe.
Here is a Wiki which shows the most common forms in the area of Financials
IfBA - Standard Driver Programs, Interface and Preconfigured Form - ABAP Development - SCN Wiki
As quoted from the whitepaper I think SAP will no longer support the sapscript forms. No matter, in case there will be a option to put in a Sapscript you will no longer get any updates with packages and that is for sure a serious problem and talk to me to move away from Sapscript and also Smartforms.
Does this answer your question?
thanks for the provided information, very helpful.
So, therefore only NAST-related processes will be replaced by the new output management and FI module is not affected as there are independent programs available.
Thanks for the great post. So as per my understanding, S/4 HANA would support those SAP Scripts which are migrated from the legacy system but for any new development of forms, one needs to use Adobe Forms / (or Smartforms) ? Kindly confirm.
That's not correct at all. You got the cahnce to maintain your already used form again, but you have to invest the time to rebuild the logic, if there is something not available. Of course there will be all tables be there at least as a view, but I'm pretty sure you need to invest time for custom-fields you read, because you won't be able to do an insert to an view 😉
Hi. This looks quite interesting. But as far as I have understood, the old processing types 5 and 8 for non-print output and EDI are not supported as of yet. How is that planned?
Thank you for posting this information.
Many of our users currently use SAP device type print controls to call printer resident fonts (MICR, barcodes, signatures, etc.), and my understanding is that they typically rely on SAPscript and Smartforms to facilitate that. Will S/4 and Adobe interactive forms allow for the use of printer resident fonts in a similar manner?
It is also possible, but I don't think there is a need for it, because you can install the font on the server and use it afterwards inside the form, which makes the process to get rid of specific printers /settings a lot easier.
Thanks for your great blog!
We are planning to do some new forms within SAP ECC 6.0 in this year. And next year we're planning to migrate to S/4HANA. So there are 2 ways for realizing the new forms now:
From your point of view would it be better to use adobe forms in SAP ECC 6.0 to reduce the migration effort next year when we go to S/4HANA?
Thanks in advance.