SAP Smart Forms Best Practices

By | March 4, 2013 | Forms, Guidelines | 20,027 | 6

Many times, I come across lot of Design Issues in Smart Forms. So, thought of compiling a list o best practices.


Majority of clients where I have consulted so far, I have seen many Smart Forms in Production system. Adobe Forms are there which gives more advantages, but Developers are more comfortable with Smart Forms so they are investing in Smart Forms. As part of my QA review responsibility, I come across Smart Forms which would work fine but have lot of “design” related issues.

Best Practices

Here are few of DOs and DONTs when working and designing a Smart Forms.

Don’t slam Code lines

Many times, Code lines are slammed with lot of code.

Few reasons, you should NOT slam code lines node within the Smart Forms.

  • Very small Editor: When you open the ABAP Editor to maintain the Code Lines, you would notice a very small window. If you are using a “normal” screen, you would run into double scrollbar issue as well. Since it is having double scroll bar and small editor, it would be difficult to write a code within it.
  • Difficult to find: Since Code lines can exist at any node level, it would be very difficult to navigate when required to find a specific code lines
  • Commented Code: Commented code in the beginning of the program lines, makes it more difficult to determine if there is any code or not.

Instead, you should think about alternative approaches:

  • Code Lines Node Usage: Use it only to do formatting on the data Code lines should be used for very few lines of code.
  • Segregation of the Logic: Try to wrap the logic in an Object or a FM which can be easily called in more than one places. This would give you an opportunity to re-factor your code, write an ABAP Unit test case, Inherit existing functionality (if ABAP Objects is used)

Rename each and every Node and its description

Justifications to rename every node

  • Unclear Purpose: If you don’t rename difficult to navigate and understand the purpose of the node. Its difficult to find relevant node and locate it. You can search the text in the FM by if the node is not renamed properly it won’t find it
  • Without proper naming, nodes would be like:

    Properly documented node will help you and others to understand the purpose of the node:

  • Translation in SE63: Without proper name of the text node, it will appear like a TEXT01 TEXT02 etc. You would need to pay lot of extra attention to make sure you put the correct translation to correct node.
  • Without proper name, you will see this in SE63 while translating the SmartForms

    With Proper Name, you would see nicely named text symbols in SE63:

Inactive Nodes

Many a times developers use 1=2 in condition to make that element “Inactive” from the form. This technique is fine as you want to retain that node and relevant logic within it. But, not maintaining proper documentation would make maintenance difficult. So, Make sure you update the description with phrase like COMMENTED, NOT USED, INACTIVE, etc.

Eventually in subsequent changes, these inactive nodes must be removed from the form. Too many inactive nodes will take long time for From to process.

Without Properly commented node, would be lost in the node tree of the Smartforms:

With proper comments, easy to find Inactive nodes:

Avoid Using Templates

Template needs definite space on the form. If you have many templates in single window which are conditionally printed on the form, Form will not complaint about the height of the window at time of Syntax check. This error will occur at run time and would be difficult to track.

Try to use LOOP with TABLE LINE. This will make sure that you don’t need definite space when you are printing dynamically.

Error Handling

After each generated FM call, make sure you get the errors as well whenever there is any exception. Call FM SSF_READ_ERRORS to retrieve the error message. Pass these message back to the NAST protocol if the SmartForm is being called from the Output control.

SmartForms Error Handling

CALL FUNCTION lf_fm_name
                archive_index        = toa_dara
                archive_parameters   = arc_params
                control_parameters   = ls_control_param
                mail_recipient       = ls_recipient
                mail_sender          = ls_sender
                output_options       = ls_composer_param
                user_settings        = space
     importing  job_output_info      = ls_job_info
     EXCEPTIONS formatting_error     = 1
                internal_error       = 2
                send_error           = 3
                user_canceled        = 4
                OTHERS               = 5.
IF sy-subrc <> 0.
* get smart form protocoll
* add smartform protocoll to nast protocoll
              MSG_NR    = <FS_ERRORTAB>-MSGNO
              MSG_TY    = <FS_ERRORTAB>-MSGTY
              MSG_V1    = <FS_ERRORTAB>-MSGV1
              MSG_V2    = <FS_ERRORTAB>-MSGV2
              MSG_V3    = <FS_ERRORTAB>-MSGV3
              MSG_V4    = <FS_ERRORTAB>-MSGV4
              OTHERS    = 1.


Since many of the developers feel comfortable putting break point in the code lines for debugging purpose even though you can achieve Smartforms: Dynamic Breakpoints. If you have hard coded break point it would make it difficult for you to debug the same form in Quality system, where you don’t have access to remove the form. You would think, “Oh man, Why didn’t I remove this?”

Do you follow any other Best Practice?

Please let me know, if there is any other best practice, you are following.

Like It? Share!!

Don't miss an Update

Get notified of the new post, right into your inbox

Naimesh Patel{273 articles}

I'm SAP ABAP Consultant for more than a decade. I like to experiment with ABAP especially OO. I have been SDN Top Contributor.
Follow :

Explore all of his 273 articles.

Load comments


  • Anand

    Very useful article.

  • Naimesh,

    These are very useful advices. Developers should be good writers who are good at grammar, punctuation, paragraphs. Developing a program or form is like a writing an essay, so the content/functionality is important but appearance, usability, readability is very important too.

  • Hello Tuncay,

    Absolutely agree with you. Writing or Designing any program / form / object is kind of “Art” – More you practice, more it becomes perfect.

    Naimesh Patel

  • Mehul

    Excellent point on error handling.

  • Wouter

    Could someone explain the use of nast protocol update? I first thought this is only used in sapscripts, but SF, and Adobe form as well?

    Where can we retrieve this information after the print?

  • Hello Wouter,

    The purpose of the NAST Protocol is for error handling of the Outputs. Whenever Output fails for any reason, it should be logged in the NAST protocol. If it is done correctly, it would be available in the processing log of the output. That way, it would be communicated to user if their output got successfully processed or not.

    There are few other FMs which can be helpful to get the NAST protocol. I would soon try to write a post about it.

    Naimesh Patel

Comments on this Post are now closed. If you have something important to share, you can always contact me.

You seem to be new here. Subscribe to stay connected.