ABAP Developmentintermediate

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

Key takeaway

Design the Smart Form interface: DDIC types for import parameters and tables, global definitions (data, types, field symbols), initialization code, form routines, and why a clean data contract between driver and form matters.

Explanation

📌 KEY POINTS
✅ Form interface = data contract: the driver passes import parameters (structures) and tables with DDIC types (SE11).
✅ Global definitions hold working variables, work areas for loops, and types; initialization code runs once before output.
✅ Use DDIC structures/table types for the interface — local types can't be used across driver and form.
⚠️ Changing the interface requires changing every driver that calls the form — design it once, add optional parameters carefully.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–3 called the form. Now we design what the form receives.

━━━━━━━━━━━━━━━━━━━━
▶ 1. IMPORT PARAMETERS

Header structure, e.g. IS_HEADER TYPE ZSF_INV_HEADER (document number, dates, addresses keys, totals).
Flags or settings (e.g. IV_REPRINT TYPE FLAG).
Optional parameters with default values for backward compatibility.

━━━━━━━━━━━━━━━━━━━━
▶ 2. TABLES

Items, e.g. IT_ITEMS TYPE ZTT_INV_ITEMS (table type) in "Import" as table type (preferred) or in "Tables" tab with a structure (older style).
Other lists: partner texts, conditions, tax lines.

━━━━━━━━━━━━━━━━━━━━
▶ 3. GLOBAL DEFINITIONS

Global data: work areas for loops (GS_ITEM TYPE ZSF_INV_ITEM), counters, totals.
Types: local types for the form's internal use.
Field symbols for flexible access.
Initialization: code run before processing (e.g. compute totals, format values, read text names).
Form routines: FORM routines usable in program-lines nodes.

━━━━━━━━━━━━━━━━━━━━
▶ 4. WHAT BELONGS WHERE

Driver: all database access and business logic (prices, taxes, texts to use).
Form initialization: formatting-level calculations (totals of passed items, page-level helpers).
Nodes: display only.

━━━━━━━━━━━━━━━━━━━━
▶ 5. CURRENCY AND QUANTITY FIELDS
Pass reference fields (WAERS, MEINS) with amounts/quantities and set them in the field's "Currency/Quantity fields" tab so output is formatted correctly.

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

SE11: create ZSF_INV_HEADER, ZSF_INV_ITEM and table type ZTT_INV_ITEMS.
SMARTFORMS: define IS_HEADER and IT_ITEMS in the interface, GS_ITEM and GV_TOTAL in global data.
Compute GV_TOTAL in initialization (code example) and display it in a window.

✅ CHECKPOINT: your form has a clean, typed interface and only presentation logic inside.

Code example

ABAP Code

* ===== SE11 objects (interface contract) =====* Structure ZSF_INV_HEADER : VBELN, FKDAT, KUNAG, NAME1, WAERK, NETWR, SPRAS* Structure ZSF_INV_ITEM   : POSNR, MATNR, ARKTX, FKIMG, VRKME, NETWR, WAERK* Table type ZTT_INV_ITEMS : line type ZSF_INV_ITEM * ===== Form interface (SMARTFORMS -> Global Settings -> Form Interface) =====* Import: IS_HEADER  TYPE ZSF_INV_HEADER*         IT_ITEMS   TYPE ZTT_INV_ITEMS*         IV_REPRINT TYPE FLAG  (optional, default space) * ===== Global definitions -> Global data =====* GS_ITEM   TYPE ZSF_INV_ITEM      work area for the item table loop* GV_TOTAL  TYPE NETWR             total of items* GV_COUNT  TYPE I * ===== Global definitions -> Initialization =====* Input parameters : IT_ITEMS* Output parameters: GV_TOTAL GV_COUNTDATA ls_item TYPE zsf_inv_item.CLEAR: gv_total, gv_count.LOOP AT it_items INTO ls_item.  gv_total = gv_total + ls_item-netwr.  gv_count = gv_count + 1.ENDLOOP. * ===== Global definitions -> Form routines (usable in program lines) =====FORM format_matnr USING iv_matnr TYPE matnr CHANGING cv_text TYPE c.  CALL FUNCTION 'CONVERSION_EXIT_MATN1_OUTPUT'    EXPORTING input = iv_matnr IMPORTING output = cv_text.ENDFORM. * ===== Text node output (fields in &...&) =====* Total: &GV_TOTAL& &IS_HEADER-WAERK&* -> set GV_TOTAL reference field IS_HEADER-WAERK in the Currency/Quantity tab

Real project scenario

An order confirmation form used local types in its interface, copied by five driver programs. When a field was added, three drivers failed with runtime errors because their local copies of the structure differed.
Moving the interface to DDIC structures and table types fixed the mismatch permanently; new fields could be added at the end of the structure without breaking any caller.

Common mistakes

Local types in the interface.
SELECTs in initialization.
Missing currency/unit reference fields.
Changing mandatory interface parameters without updating drivers.
Global variables not cleared between documents.

Best practices

DDIC structures and table types for the interface.
Optional parameters for extensions.
Initialization only for presentation calculations.
Set currency/quantity references.
Document the interface contract.

Interview angle

Questions: "What is the form interface?", "What goes into global definitions and initialization?", "Where should data selection happen?"
Strong answer: interface defines import parameters/tables with DDIC types as contract with drivers; global data for work areas/totals, types, field symbols; initialization for presentation calculations; form routines for program lines; data selection in the driver; currency/quantity references for amounts.

Practice this lesson

Quick check

1. Why should the Smart Form interface use DDIC structures and table types?

2. Where do you calculate an invoice total from the passed item table in the form?

3. Where should heavy data selection for a SmartForm usually be done?

Interview questions

1. A purchase order form originally received the full EKKO and EKPO tables and did many calculations itself. How would you redesign its interface?

Answer it in your own words first, then compare.

2. How do you design a maintainable SmartForm solution?

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.