Moving to S/4 – What about your output management?

Hi all,

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

The motivation

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

2.1.2.14 Billing Document Output Management

2.1.2.14.1 Description

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:

https://help.sap.com/s4hana_op_1511

Additional to that there are more than this part which aims to the output management. You can common information under Top Cross Application – point 2.1.39.1Output Management

For me the important snippet is:

Print Technology: The SAP S/4HANA Output Management supports the following print technologies:

o SmartForms

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

Overview

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.

Planning

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;-)

Getting started

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

http://scn.sap.com/community/output-management/blog/2014/04/02/10-tips-how-to-make-a-smartform-easier-and-more-readable

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 😆

http://xkcd.com/303/

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?

That’s it.

Feel free to leave a comment or to add your personal statements about your experience. What way do you use to handle it?

~Florian

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 😛