ERPClimb logoERPClimb
Login
SmartForms
ABAP Developmentbeginner

Smart Forms Part 1: What Smart Forms Are and How Printing Works

Key takeaway

Understand SAP Smart Forms: transaction SMARTFORMS, the generated function module, the driver (print) program, form interface, pages and windows, Smart Styles, output control, and how Smart Forms compare with SAPscript and Adobe Forms.

What this complete series covers

Learn SmartForms in a clear, practical sequence — from the basic idea to real project use, troubleshooting, and interview-ready understanding.

Who it is for
Best for SAP consultants, developers, and learners who want a practical understanding of SmartForms.
Prerequisites
Basic SAP navigation and ABAP syntax help. For hands-on practice, use an ABAP system with ADT or the relevant ABAP development tools.
Final outcome
By the end, you should be able to explain SmartForms clearly, follow the main end-to-end flow, apply it in a project scenario, and troubleshoot the most common issues.
  1. Part 1: Smart Forms Part 1: What Smart Forms Are and How Printing Works

    Build Smart Form driver programs as orchestration layers that prepare final business data, resolve the generated form function dynamically and separate output configuration from layout logic.

  2. Part 2: Smart Forms Part 2: Anatomy of a Smart Form and the Driver Program

    Understand the Smart Form architecture from driver program and form interface through the generated runtime function module, control parameters, layout nodes and spool output.

  3. Part 3: Smart Forms Part 3: Output Determination and the Print Program Entry

    Troubleshoot Smart Form output end to end: determine whether output was created, whether the driver program ran, whether the generated form function module received correct data, a

  4. Part 4: Smart Forms Part 4: Form Interface — Import Parameters, Tables and Global Data

    Treat the Smart Form interface as the contract between driver and layout: pass final typed header, item and text data explicitly, keep global form data minimal and avoid coupling t

  5. Part 5: Smart Forms Part 5: Pages, Windows and Main Window Flow

    Design Smart Form pagination around the MAIN window for variable-length content, using secondary windows only for fixed-position information whose height is predictable.

  6. Part 6: Smart Forms Part 6: Tables, Templates, Loops and Conditions

    Use Smart Form table nodes for repeating dynamic rows, templates for fixed grid layouts and simple conditions driven by flags prepared in the driver program.

  7. Part 7: Smart Forms Part 7: Texts, Translations and Language Handling

    Design multilingual Smart Forms by determining the business document language in the driver, using translated text elements or standard texts and keeping hard-coded language-specif

  8. Part 8: Smart Forms Part 8: Debugging Smart Forms and Generated Function Modules

    Debug Smart Form incidents by separating output determination, driver data, generated function-module invocation, form binding and final spool or delivery status.

System and release assumptions: Examples follow modern ABAP practices. Exact syntax, available APIs, and tools can vary by SAP release, so release-dependent points are called out where needed.

Explanation

📌 KEY POINTS
✅ A Smart Form is a form layout designed in transaction SMARTFORMS; on activation SAP generates a function module (/1BCDWB/SF…) that prints it.
✅ A driver program reads the business data and calls the generated FM — found by SSF_FUNCTION_MODULE_NAME, because its name differs per system.
✅ Layout = pages, windows (main and secondary), texts, tables, graphics; formatting via Smart Styles (SMARTSTYLES).
⚠️ Keep data selection in the driver program, not inside the form — forms with SELECTs are slow, hard to test and hard to reuse.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS

  • Part 1 — what Smart Forms are (this lesson)
  • Part 2 — anatomy and driver program
  • Part 3 — output determination and debugging the print call
  • Part 4 — form interface: import parameters, tables, global data
  • Part 5 — pages, windows and main window flow
  • Part 6 — tables, templates and conditions
  • Part 7 — texts, translations and language handling
  • Part 8 — debugging Smart Forms and the generated FM

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHERE SMART FORMS ARE USED
Invoices, order confirmations, delivery notes, purchase orders, labels, custom letters — mainly in ECC and S/4HANA on-premise systems that use output control (NACE).

━━━━━━━━━━━━━━━━━━━━
▶ 2. BUILDING BLOCKS

  • Form interface: parameters the driver passes (e.g. IS_HEADER, IT_ITEMS).
  • Global definitions: variables, types, field symbols, initialization code.
  • Pages and windows: layout areas; the main window flows over pages.
  • Nodes: text, table, template, loop, condition, program lines, graphic, address.
  • Smart Style: paragraph and character formats.

━━━━━━━━━━━━━━━━━━━━
▶ 3. PRINT FLOW
Driver program → SSF_FUNCTION_MODULE_NAME (form name → FM name) → CALL FUNCTION lv_fm with control parameters (printer, preview) and data → spool (SP01) or preview/PDF.

━━━━━━━━━━━━━━━━━━━━
▶ 4. SMART FORMS VS SAPSCRIPT VS ADOBE FORMS

  • SAPscript (SE71): oldest, client-dependent, text-based layout; still in many standard forms.
  • Smart Forms: graphical, client-independent, generated FM; widely used in ECC.
  • Adobe Forms (SFP): PDF-based, required for many S/4HANA output scenarios and interactive forms; SAP's strategic form technology.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

  1. SMARTFORMS: display SF_EXAMPLE_01 and look at its interface, pages and windows.
  2. Test it (F8) to see the generated FM name.
  3. Run the demo driver SF_EXAMPLE_01 in SE38 (flight data) and preview.

✅ CHECKPOINT: you know the parts of a Smart Form and the basic print flow.

Code example

ABAP Code
* ===== Minimal Smart Form call from a driver program =====REPORT zsf_demo. PARAMETERS p_form TYPE tdsfname DEFAULT 'ZSF_INVOICE'. DATA: lv_fm        TYPE rs38l_fnam,      ls_control   TYPE ssfctrlop,       " control parameters (preview, no dialog ...)      ls_output    TYPE ssfcompop,       " output options (printer, copies ...)      ls_header    TYPE zsf_inv_header,  " own structure, used in the form interface      lt_items     TYPE ztt_inv_items.   " own table type START-OF-SELECTION.* ===== Step 1: data selection in the DRIVER, not in the form =====  PERFORM get_data.                      " fills ls_header / lt_items (not shown) * ===== Step 2: find the generated FM (name differs per system) =====  CALL FUNCTION 'SSF_FUNCTION_MODULE_NAME'    EXPORTING  formname = p_form    IMPORTING  fm_name  = lv_fm    EXCEPTIONS no_form            = 1               no_function_module = 2               OTHERS             = 3.  IF sy-subrc <> 0.    MESSAGE 'Form not found or not active' TYPE 'E'.  ENDIF. * ===== Step 3: output options =====  ls_control-preview   = 'X'.            " show print preview  ls_output-tddest     = 'LP01'.         " output device * ===== Step 4: call the form =====  CALL FUNCTION lv_fm    EXPORTING      control_parameters = ls_control      output_options     = ls_output      user_settings      = space      is_header          = ls_header      it_items           = lt_items    EXCEPTIONS      formatting_error   = 1      internal_error     = 2      send_error         = 3      user_canceled      = 4      OTHERS             = 5.  IF sy-subrc <> 0.    MESSAGE ID sy-msgid TYPE 'S' NUMBER sy-msgno            WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4 DISPLAY LIKE 'E'.  ENDIF. FORM get_data.ENDFORM.

Real project scenario

A company's invoice Smart Form contained 15 SELECT statements in program-lines nodes. Printing 2,000 invoices in the nightly billing output run took hours, and every layout change risked breaking data logic.
The team moved all selection into the driver program, passed prepared structures via the form interface, and kept only formatting in the form. The run time dropped to minutes, and layout changes became safe for junior developers.

Common mistakes

  • Hard-coding the generated FM name (/1BCDWB/SF…).
  • SELECTs inside the form.
  • Using USER_SETTINGS = 'X' and ignoring passed output options.
  • Not handling exceptions of the form call.
  • Starting new forms in Smart Forms when Adobe Forms is the target technology.

Best practices

  • Always use SSF_FUNCTION_MODULE_NAME.
  • Data in the driver, formatting in the form.
  • Use Smart Styles for consistent formatting.
  • Handle exceptions and spool information.
  • Check the organisation's form strategy (Smart Forms vs Adobe).

Interview angle

Questions: "What is a Smart Form?", "Why use SSF_FUNCTION_MODULE_NAME?", "Smart Forms vs SAPscript vs Adobe Forms?"
Strong answer: graphical form in SMARTFORMS generating an FM; driver program selects data and calls the FM obtained via SSF_FUNCTION_MODULE_NAME (name differs per system); interface, global definitions, pages/windows, nodes, Smart Styles; SAPscript older client-dependent, Adobe PDF-based and strategic in S/4HANA.

Practice this lesson

Quick check

1. Where should an invoice Smart Form get its customer and tax data from?

2. Which transaction is used to maintain SmartForms?

3. Which is TRUE about SmartForms in S/4HANA?

Interview questions

1. What is a SmartForm in SAP ABAP?

Answer it in your own words first, then compare.

2. In S/4HANA, should new output be built in SmartForms?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics