Showing posts with label Adobe Forms. Show all posts
Showing posts with label Adobe Forms. Show all posts

Jul 6, 2022

Understanding S/4 HANA Adobe Forms for Functional Consultants

SAP has used over the past (many) years different technologies and development languages to build outputs / printouts for different processes (Ex. PO printout, Customer Invoice and/or Check printing and many more too). Some of these technologies can still be used if you want, but now a days you have better, easier and a more robust technology that can be used. This is Adobe Lifecycle Forms in S/4 HANA or some call them Adobe forms.

In the past, we used to do many of these mentioned outputs with SAPScript technology. These was ok for that time, but it is a little bit of a tedious language and adjusting drawings and positions takes a lot of try & error and definitively not really user friendly. Also, if you needed extra information that was not part or accessible in the original SAP delivered form; you most likely needed to create a "custom print program" to be able to accommodate the extra info or logic needed. We all know by know what custom means in terms of future upgrades and maintenance costs ...

Then after SAPScript came Smartforms, which it was the 1st possibility of dealing and producing Adobe PDF type of outputs. I worked with it a bit, but unfortunately being a Finance consultant I still had to deal with SAPScript as Smartforms was not widely available or used in Finance. It was more available for modules like SD for their Customer Invoices and related outputs.

But today since the inception of S/4 HANA, SAP has introduced a newer, better and more user friendly technology called "Adobe Forms".

Before being able to use this technology, some technical pre-requisites need to be in place in your S/4 HANA environment which your Basis and infrastructure team will have to work on it first. For this to work, you will an ADS Server (Adobe Document Server) to be installed in your landscape. And this runs in JAVA, so you will need to install it in a JAVA based server. I know from the past that the PI/PO server was JAVA based, so a couple of clients were sharing it for both technologies. Once that is in place, then they will have to connect them and after that you will be able to start using it. If you try to use it without this being in place, you will get a lot of errors and you will not even be able to display a form nor create one.

It is funny that I have to highlight that, as one would think this should be standard out of the box for any S/4 implementation; but apparently it is not ... This year, I went into a client where another SI was kicked out for doing a terrible job, and among many of my findings were that these guys designed all the outputs by still using the old SAPScript technology and the ADS server was non-existent in the client landscape.

Note: Don't ask me more technical questions about the ADS server as I am just a Functional guy, not a Basis resource.

How do we use and deal with these forms in S/4 HANA ?

As we were used to before with SAP, they have delivered a series of standard forms for each of the available outputs for the different processes that we can always leverage to start from them and add / remove / modify them as we see fit as per client requirements. Like adding a logo, changing columns or adding extra information that is not standard delivered.

As usual and in proper development practices, you should "never" modify an SAP standard form. You should ALWAYS create a copy and work with your own custom form. 

To access these forms, you can use Tcode SFP and enter (or search) the form name that you want to work with.


In my example, I will be working with the Vendor Payment Advice form which is a typical form that we use in Finance for payments.

Then you go Display and you will start looking at the definition and design of the Form. 

Within the Context tab, you will see a lot of the Structures that the form deals with and their individual fields that are available for the form to be added in the output. 


Here you can browse through the different Structures and fields and can take note of any extra fields that you might want to include in your customized form to add it to you Functional Specification document so then your Abaper can add them.
From my example (Payment Advice), you can clearly identify these structures as being the ones that are also available when we execute payments or when we build or deal with DMEE's. So any field that you want from those structures can be added to your form. There are fields at the header level and line item as usual. Same for any other forms for any other processes.

If for example, I want to add to my form "Payee Bank account #" and "Payee Bank Name", I just need to provide those technical field names (ZBNKN and ZBNKA) to be added to the form. 



Another possibility that you have, is to go to the Properties Tab and double click in the Interface name (Ex. FI_FPAYM_DATA). These will bring you another screen where you can then display the Structures definitions that we were seeing in the prior step in a more technical way as if you were displaying them in SE12.





Or, you can copy the Interface name and paste it right when you call Tcode SFP in the Interface field and display it. (Same result).

After you double click in any of the Type Name's for the Import Form Interface, you will see that structure the same way as you would see it in SE12 with all its technical definition, data type, length and so on ... Very useful when you want to see how big is the information you will be adding / removing to/from your form.

Next ... If you want to take a look at a draft layout of the final output form, you need to go back to the beginning to the "Layout" tab.

Before you are able to display the form layout in a PDF like way, you need to install Adobe Lifecycle Designer in your computer. In your own PC, not in the SAP server. Without that, you will not be able to display the form here in SFP. You can download it from the SAP Marketplace and then install it. 

Then you will see in the center of your screen, a little bit of a PDF display that also contains some technical information about the fields mapping (see below).


When you move to the left pane and drill down in parts of that hierarchy, the part that you are clicking on will get highlighted in the form just beside it in the central part of your screen. 
Also, if you see the right bottom pane, you will be able to see the field "binding" (field that is assigned to) for that field too.

All of these information will help you navigate through the form for you to do your analysis on which fields you need to add or remove from your form and provide a better Functional Specification Document (FSD) with detailed information and not just screen fields like I have seen many Functional consultants doing in the past (and still today ...).

Once your Developer finishes doing the changes in the form, you will just need to update the configuration for the process to include the new form name and it will be ready to be called by the system

Finally ...

What if I need to add fields that are not part of the structures that are available already in the form ?
What if I need to add custom logics to derive those fields or read other tables from other modules (Ex. SD or MM) ? How can I do that ?

In the past, to achieve this we needed to end up doing a Z / Custom program. Take a copy of the standard program and modify it as I mentioned earlier on.

Today with Adobe forms, there is NO MORE NEED TO CREATE A CUSTOM PRINT PROGRAM. If you see someone (Abap or functional) trying to repeat those old habits from the past. STOP HIM right away !!! That person has not updated his skills to S/4 HANA. 

There is absolutely no need for a Custom print program anymore. ZERO !!!

Any custom logics, fields, calculations, Abap code can be accommodated inside of the form where there is a section for you to put your own code, Form Routines and Data Definitions. I will not tell you how to do this part exactly because I am not an Abaper, but he should go back and investigate that as it is pretty simple to do in Adobe Forms.

Once he added the custom code to the form, you will be able to obtain the expected results and no SAP code would have been modified and this form will continue to be called by standard SAP programs.

This last part is really important, as I have passed through S/4 clients in the last years and I have seen Functional consultants that still asked for a custom print program and also delivered a form by using SAPScript. That should not be the approach for S/4 HANA anymore !

The technology stills exists and is still available for you to use it if you want. But you should not use it as you will be using old technology and not benefiting from the latest innovations. (Can you still work with a Monochrome amber or green screen ? for certain things probably yes. But there are better monitors now a days. So this is the same ...).


If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

Aug 12, 2020

How to do (print) physical Checks with SAP S/4 HANA the new / right way !

For many of us that have been around for a while in the SAP Finance world, designing Checks is a constant on every project. I lost count how many Checks I have designed and implemented over the last 11 years, but I can tell you, I know quite a bit about it and have done it many times. I have designed Checks for Small, Medium and Large companies in Canada and in the US too. (For you guys in Europe, Checks are something of the past since 2014 and the introduction of SEPA, lucky you !).

I am also writing this as I have been asked several times by different colleagues on how this should be done in S/4 HANA as not a lot of Consultants know this already and have upgraded their skills to S/4.

So ... As many of you know by now (if not you should not be doing SAP anymore), things have changed in S/4 HANA (for the better) compared to the tools and ways of implementing Checks in ECC6.0 and before.

Developers have new tools to design FORMs like Adobe Forms with Adobe Lifecycle Designer that you should use instead of the old SAPScript. It is lot easier, faster, more user friendly and gives you a lot of flexibility to implement custom code.

So ... now, How should you be doing checks in S/4 HANA the new and right way ?

There are a couple of things that you should consider now in S/4 HANA. By now, you should not be deploying anymore the old SAP GUI logon Pad. There are certain exceptions, but you should deliver the new UI which is SAP Fiori. With that it comes a lot of new Apps that have been built for Finance. Among those you will find "Manage Automatic Payments" that replaces to old Automatic Payment Program Tcode F110. 

The new "Manage Automatic Payments" App is more user friendly, more intuitive and have lost several of the technical non-sense things that an end-user needed to select in order to issue Payments in SAP. I never understood why they made it so complicated for the end user (well it's SAP ...). 



Now the Tab "Printout/data medium" is gone from the Fiori App, you do not have access anymore to that Tab. It just does not exist in Fiori such an option to select what variants you will be using for each program. Instead you should be using the new Standard delivered Payment Medium Workbench (PMW) CHECK.

You cannot use anymore the old and traditional program RFFOUS_C (or any similar variant of it). Also, you cannot use the traditional Funds Transfer / Electronic payment program RFFOUS_T and you should be using the PMW and build a DMEE for Electronic Funds Transfer instead.  This is "IF" you want to use the new Fiori App, if you don't and you still want to use the old F110, then those programs will still work in S/4 HANA. But why would you want to keep on using it if you have a new one ? Would you keep driving your old car with no AC, no power windows and no power steering wheel ? Well, I don't !!!

Not long ago, I went into a client who was running S/4 (greenfield implementation) and saw that they were using the traditional RFFOUS_C Print program. In fact, they took a copy of the program and they customized and put their own code inside it. This is something that we all used to do in the old ECC days, but we should not do this anymore. (See below what we should not do anymore).

Unless you have a compelling technical reason for using the old Print Program, then I see this as poor knowledge and lack of skills from the Consultant that implemented this solution. Which it wouldn't be the first time I see someone that lacks the technical knowledge doing something like this ...

 

As I mentioned before, YOU SHOULD STOP USING RFFOUS_C and start using the new SAP Standard delivered Payment Medium Workbench CHECK to be able to print Checks.

Another thing you should STOP doing is using SAPScript to design your Check Form layout. The new way in S/4 and new tool is Adobe Forms (not Smartforms). SAP Delivers a Standard form that you should take as a reference and design your own as per your business requirements. 

Adobe Lifecycle Designer will allow your Developer to meet 100% of your Business requirements Layout and add any type of custom code needed to retrieve any extra information that could be required to be printed in the form that is not yet available . No more copying the Standard program and modifying it so then the SAPScript form has access to new information. That is not needed anymore with this new technology. A good and up-to-date Abaper will know what I am talking about. (It is not the purpose of this post to explain that and I am not an Abaper either).

After you have configured the use of the Payment Medium Workbench CHECK and have developed your custom Adobe Form, you should add it in the configuration. After that your config should not have this setup anymore.

In the line "Form for the Payment Medium" you should select PDF and enter your PDF Form name there instead of SAPScript.

After that you need to configure your Variants in Transaction OBPM4.


There you will create a Variant which will allow you to select your Check Printer among some other things.

As you can see, it is not complicated, you just have to know how to do it and your SAP Finance Consultant should have up to date knowledge too.

I am putting as a reference 2 OSS Notes that explain part of this new setup and gives you a possibility of using the Old programs if you still want. But I would not recommend it, it is not the way to go these days and I suspect that eventually SAP could close that door in subsequent versions.


Note: The described procedure and screens belong to S/4 HANA On-premise.


If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

Reference OSS Notes:


2794915 - No "Printout/data medium" tab in "Manage Automatic Payments"
https://launchpad.support.sap.com/#/notes/2794915


2418837 - Manage Automatic Payments: Add Support for Classic Payment Medium Programs
https://launchpad.support.sap.com/#/notes/2418837